Methods and apparatus for a distributed database within a network

ABSTRACT

In some embodiments, an apparatus includes an instance of a distributed database at a first compute device configured to be included within a set of compute devices that implement the distributed database. The apparatus also includes a processor configured to define a first event linked to a first set of events. The processor is configured to receive, from a second compute device from the set of compute devices, a signal representing a second event (1) defined by the second compute device and (2) linked to a second set of events. The processor is configured to identify an order associated with a third set of events based at least one a result of a protocol. The processor is configured to store in the instance of the distributed database the order associated with the third set of events.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.15/153,011, filed May 12, 2016, titled “Methods and Apparatus for aDistributed Database within a Network,” which is a continuation-in-partof U.S. patent application Ser. No. 14/988,873, filed Jan. 6, 2016 andtitled “Methods and Apparatus for a Distributed Database within aNetwork,” now U.S. Pat. No. 9,390,154, which claims priority to and thebenefit of U.S. Provisional Patent Application No. 62/211,411, filedAug. 28, 2015 and titled “Methods and Apparatus for a DistributedDatabase within a Network,” each of which is incorporated herein byreference in its entirety.

U.S. patent application Ser. No. 15/153,011 also claims priority to andthe benefit of U.S. Provisional Patent Application No. 62/211,411, filedAug. 28, 2015 and titled “Methods and Apparatus for a DistributedDatabase within a Network,” which has been incorporated herein byreference in its entirety.

BACKGROUND

Embodiments described herein relate generally to a database system andmore particularly to methods and apparatus for implementing a databasesystem across multiple devices in a network.

Some known distributed database systems attempt to achieve consensus forvalues within the distributed database systems (e.g., regarding theorder in which transactions occur). For example, an online multiplayergame might have many computer servers that users can access to play thegame. If two users attempt to pick up a specific item in the game at thesame time, then it is important that the servers within the distributeddatabase system eventually reach agreement on which of the two userspicked up the item first.

Such distributed consensus can be handled by methods and/or processessuch as the Paxos algorithm or its variants. Under such methods and/orprocesses, one server of the database system is set up as the “leader,”and the leader decides the order of events. Events (e.g., withinmultiplayer games) are forwarded to the leader, the leader chooses anordering for the events, and the leader broadcasts that ordering to theother servers of the database system.

Such known approaches, however, use a server operated by a party (e.g.,central management server) trusted by users of the database system(e.g., game players). Accordingly, a need exists for methods andapparatus for a distributed database system that does not require aleader or a trusted third party to operate the database system.

Other distributed databases are designed to have no leader, but areinefficient. For example, one such distributed database is based on a“block chain” data structure, which can achieve consensus. Such asystem, however, can be limited to a small number of transactions persecond total, for all of the participants put together (e.g., 7transactions per second), which is insufficient for a large-scale gameor for many traditional applications of databases. Accordingly, a needexists for a distributed database system that achieves consensus withouta leader, and which is efficient.

SUMMARY

In some embodiments, an apparatus includes an instance of a distributeddatabase at a first compute device configured to be included within aset of compute devices that implement the distributed database. Theapparatus also includes a processor configured to define a first eventlinked to a first set of events. The processor is configured to receive,from a second compute device from the set of compute devices, a signalrepresenting a second event (1) defined by the second compute device and(2) linked to a second set of events. The processor is configured toidentify an order associated with a third set of events based at leastone a result of a protocol. The processor is configured to store in theinstance of the distributed database the order associated with the thirdset of events.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high level block diagram that illustrates a distributeddatabase system, according to an embodiment.

FIG. 2 is a block diagram that illustrates a compute device of adistributed database system, according to an embodiment.

FIGS. 3-6 illustrate examples of a hashDAG, according to an embodiment.

FIG. 7 is a flow diagram that illustrates a communication flow between afirst compute device and a second compute device, according to anembodiment.

FIG. 8 is a flow diagram that illustrates a communication flow between afirst compute device and a second compute device, according to anembodiment.

FIGS. 9a-9c are vector diagrams that illustrate examples of vectors ofvalues.

FIGS. 10a-10d are vector diagrams that illustrate examples of vectors ofvalues being updated to include new values.

FIG. 11 is a flow chart that illustrates operation of a distributeddatabase system, according to an embodiment.

FIG. 12 is a flow chart that illustrates operation of a distributeddatabase system, according to an embodiment.

FIG. 13 is a flow chart that illustrates operation of a distributeddatabase system, according to an embodiment.

FIG. 14 is an example of a hashDAG, according to an embodiment.

FIG. 15 is an example of a hashDAG, according to an embodiment.

FIGS. 16a-16b illustrate an example consensus method for use with ahashDAG, according to an embodiment.

DETAILED DESCRIPTION

In some embodiments, an apparatus includes an instance of a distributeddatabase at a first compute device configured to be included within aset of compute devices that implement the distributed database via anetwork operatively coupled to the set of compute devices. The apparatusalso includes a processor operatively coupled to the memory storing theinstance of the distributed database. The processor is configured todefine, at a first time, a first event linked to a first set of events.The processor is configured to receive, at a second time after the firsttime and from a second compute device from the set of compute devices, asignal representing a second event (1) defined by the second computedevice and (2) linked to a second set of events. The processor isconfigured to identify an order associated with a third set of eventsbased at least one a result of a protocol. Each event from the third setof events being from at least one of the first set of events or thesecond set of events. The processor is configured to store in theinstance of the distributed database the order associated with the thirdset of events.

In some instances, each event from the third set of events is associatedwith a set of attributes (e.g., sequence number, generation number,round number, received number, and/or timestamp, etc.). The result ofthe protocol can include a value for each attribute from the set ofattributes for each event from the third set of events. The value for afirst attribute from the set of attributes can include a first numericvalue and the value for a second attribute from the set of attributescan include a binary value associated with the first numeric value. Thebinary value for the second attribute (e.g., a round increment value)for an event from the third set of events can be based on whether arelationship between that event and a fourth set of events linked tothat event satisfies a criterion (e.g., a number of events stronglyidentified by that event). Each event from the fourth set of events is(1) an ancestor of the event from the third set of events and (2)associated with a first common attribute as the remaining events fromthe fourth set of events (e.g., a common round number, an indication ofbeing a round R first event, etc.). The first common attribute can beindicative of a first instance that an event defined by each computedevice from the set of compute devices is associated with a firstparticular value (e.g., an indication of being a round R first event,etc.).

The value for a third attribute (e.g., a received round number) from theset of attributes can include a second numeric value based on arelationship between the event and a fifth set of events linked to theevent. Each event from the fifth set of events is a descendant of theevent and associated with a second common attribute (e.g., is famous) asthe remaining events from the fifth set of events. The second commonattribute can be associated with (1) a third common attribute (e.g.,being a round R first event or a witness) indicative of a first instancea second event defined by each compute device from the set of computedevices is associated with a second particular value different from thefirst particular value and (2) a result based on a set of indications.Each indication from the set of indications can be associated with anevent from a sixth set of events. Each event from the sixth set ofevents can be associated with a fourth common attribute indicative of afirst instance a third event defined by each compute device from the setof compute devices is associated with a third particular value differentfrom the first particular value and the second particular value. In someinstances, the first particular value is a first integer (e.g., a firstround number R), the second particular value is a second integer (e.g.,a second round number, R+n) greater than the first integer and the thirdparticular value is a third integer (e.g., a third round number, R+n+m)greater than the second integer.

In some embodiments, an apparatus includes a memory and a processor. Thememory includes an instance of a distributed database at a first computedevice configured to be included within a set of compute devices thatimplements the distributed database via a network operatively coupled tothe set of compute devices. The processor is operatively coupled to thememory storing the instance of the distributed database and isconfigured to receive a signal representing an event linked to a set ofevents. The processor is configured to identify an order associated withthe set of events based at least on a result of a protocol. Theprocessor is configured to store in the instance of the distributeddatabase the order associated with the set of events.

In some embodiments, a non-transitory processor-readable medium storescode representing instructions to be executed by a processor to receivea signal representing an event linked to a set of events and identify anorder associated with the set of events based on a round associated witheach event from the set of events and an indication of when to incrementthe round associated with each event. The code further includes code tocause the processor to store, in an instance of a distributed databaseat a first compute device configured to be included within a set ofcompute devices that implements the distributed database via a networkoperatively coupled to the set of compute devices, the order associatedwith the set of events. The instance of the distributed database isoperatively coupled to the processor

In some embodiments, an instance of a distributed database at a firstcompute device can be configured to be included within a set of computedevices that implements the distributed database via a networkoperatively coupled to the set of compute devices. The first computedevice stores multiple transactions in the instance of a distributeddatabase. A database convergence module can be implemented in a memoryor a processor of the first compute device. The database convergencemodule can be operatively coupled with the instance of the distributeddatabase. The database convergence module can be configured to define,at a first time, a first event linked to a first set of events. Eachevent from the first set of events is a sequence of bytes and isassociated with (1) a set of transactions from multiple sets oftransactions, and (b) an order associated with the set of transactions.Each transaction from the set of transactions is from the multipletransactions. The database convergence module can be configured toreceive, at a second time after the first time and from a second computedevice from the set of compute devices, a second event (1) defined bythe second compute device and (2) linked to a second set of events. Thedatabase convergence module can be configured to define a third eventlinked to the first event and the second event. The database convergencemodule can be configured to identify an order associated with a thirdset of events based at least on the first set of events and the secondset of events. Each event from the third set of events is from at leastone of the first set of events or the second set of events. The databaseconvergence module can be configured to identify an order associatedwith the multiple transactions based at least on (1) the orderassociated with the third set of events and (2) the order associatedwith each set of transactions from the multiple sets of transactions.The database convergence module can be configured to store in theinstance of the distributed database the order associated with themultiple transactions stored in the first compute device.

In some embodiments, an instance of a distributed database at a firstcompute device can be configured to be included within a set of computedevices that implements the distributed database via a networkoperatively coupled to the set of compute devices. A databaseconvergence module can be implemented in a memory or a processor of thefirst compute device. The database convergence module can be configuredto define, at a first time, a first event linked to a first set ofevents. Each event from the first set of events is a sequence of bytes.The database convergence module can be configured to receive, at asecond time after the first time and from a second compute device fromthe set of compute devices, a second event (1) defined by the secondcompute device and (2) linked to a second set of events. Each event fromthe second set of events is a sequence of bytes. The databaseconvergence module can be configured to define a third event linked tothe first event and the second event. The database convergence modulecan be configured to identify an order associated with a third set ofevents based at least on the first set of events and the second set ofevents. Each event from the third set of events is from at least one ofthe first set of events or the second set of events. The databaseconvergence module can be configured to store in the instance of thedistributed database the order associated with the third set of events.

In some embodiments, data associated with a first transaction can bereceived at a first compute device from a set of compute devices thatimplement a distributed database via a network operatively coupled tothe set of compute devices. Each compute device from the set of computedevices has a separate instance of the distributed database. A firsttransaction order value associated with the first transaction can bedefined at a first time. Data associated with a second transaction canbe received from a second compute device from the set of computedevices. A set of transactions can be stored in the instance of thedistributed database at the first compute device. The set oftransactions can include at least the first transaction and the secondtransaction. A set of transaction order values including at least thefirst transaction order value and a second transaction order value canbe selected at a second time after the first time. The secondtransaction order value can be associated with the second transaction. Adatabase state variable can be defined based on at least the set oftransactions and the set of transaction order values.

As used herein, a module can be, for example, any assembly and/or set ofoperatively-coupled electrical components associated with performing aspecific function, and can include, for example, a memory, a processor,electrical traces, optical connectors, software (executing in hardware)and/or the like.

As used in this specification, the singular forms “a,” “an” and “the”include plural referents unless the context clearly dictates otherwise.Thus, for example, the term “module” is intended to mean a single moduleor a combination of modules. For instance, a “network” is intended tomean a single network or a combination of networks.

FIG. 1 is a high level block diagram that illustrates a distributeddatabase system 100, according to an embodiment. FIG. 1 illustrates adistributed database 100 implemented across four compute devices(compute device 110, compute device 120, compute device 130, and computedevice 140), but it should be understood that the distributed database100 can use a set of any number of compute devices, including computedevices not shown in FIG. 1. The network 105 can be any type of network(e.g., a local area network (LAN), a wide area network (WAN), a virtualnetwork, a telecommunications network) implemented as a wired networkand/or wireless network and used to operatively couple compute devices110, 120, 130, 140. As described in further detail herein, in someembodiments, for example, the compute devices are personal computersconnected to each other via an Internet Service Provider (ISP) and theInternet (e.g., network 105). In some embodiments, a connection can bedefined, via network 105, between any two compute devices 110, 120, 130,140. As shown in FIG. 1, for example, a connection can be definedbetween compute device 110 and any one of compute device 120, computedevice 130, or compute device 140.

In some embodiments, the compute devices 110, 120, 130, 140 cancommunicate with each other (e.g., send data to and/or receive datafrom) and with the network via intermediate networks and/or alternatenetworks (not shown in FIG. 1). Such intermediate networks and/oralternate networks can be of a same type and/or a different type ofnetwork as network 105.

Each compute device 110, 120, 130, 140 can be any type of deviceconfigured to send data over the network 105 to send and/or receive datafrom one or more of the other compute devices. Examples of computedevices are shown in FIG. 1. Compute device 110 includes a memory 112, aprocessor 111, and an output device 113. The memory 112 can be, forexample, a random access memory (RAM), a memory buffer, a hard drive, adatabase, an erasable programmable read-only memory (EPROM), anelectrically erasable read-only memory (EEPROM), a read-only memory(ROM) and/or so forth. In some embodiments, the memory 112 of thecompute device 110 includes data associated with an instance of adistributed database (e.g., distributed database instance 114). In someembodiments, the memory 112 stores instructions to cause the processorto execute modules, processes and/or functions associated with sendingto and/or receiving from another instance of a distributed database(e.g., distributed database instance 124 at compute device 120) a recordof a synchronization event, a record of prior synchronization eventswith other compute devices, an order of synchronization events, a valuefor a parameter (e.g., a database field quantifying a transaction, adatabase field quantifying an order in which events occur, and/or anyother suitable field for which a value can be stored in a database).

Distributed database instance 114 can, for example, be configured tomanipulate data, including storing, modifying, and/or deleting data. Insome embodiments, distributed database instance 114 can be a relationaldatabase, object database, post-relational database, and/or any othersuitable type of database. For example, the distributed databaseinstance 114 can store data related to any specific function and/orindustry. For example, the distributed database instance 114 can storefinancial transactions (of the user of the compute device 110, forexample), including a value and/or a vector of values related to thehistory of ownership of a particular financial instrument. In general, avector can be any set of values for a parameter, and a parameter can beany data object and/or database field capable of taking on differentvalues. Thus, a distributed database instance 114 can have a number ofparameters and/or fields, each of which is associated with a vector ofvalues. The vector of values is used to determine the actual value forthe parameter and/or field within that database instance 114.

In some instances, the distributed database instance 114 can also beused to implement other data structures, such as a set of (key, value)pairs. A transaction recorded by the distributed database instance 114can be, for example, adding, deleting, or modifying a (key, value) pairin a set of (key, value) pairs.

In some instances, the distributed database system 100 or any of thedistributed database instances 114, 124, 134, 144 can be queried. Forexample, a query can consist of a key, and the returned result from thedistributed database system 100 or distributed database instances 114,124, 134, 144 can be a value associated with the key. In some instances,the distributed database system 100 or any of the distributed databaseinstances 114, 124, 134, 144 can also be modified through a transaction.For example, a transaction to modify the database can contain a digitalsignature by the party authorizing the modification transaction.

The distributed database system 100 can be used for many purposes, suchas, for example, storing attributes associated with various users in adistributed identity system. For example, such a system can use a user'sidentity as the “key,” and the list of attributes associated with theusers as the “value.” In some instances, the identity can be acryptographic public key with a corresponding private key known to thatuser. Each attribute can, for example, be digitally signed by anauthority having the right to assert that attribute. Each attribute canalso, for example, be encrypted with the public key associated with anindividual or group of individuals that have the right to read theattribute. Some keys or values can also have attached to them a list ofpublic keys of parties that are authorized to modify or delete the keysor values.

In another example, the distributed database instance 114 can store datarelated to Massively Multiplayer Games (MMGs), such as the currentstatus and ownership of gameplay items. In some instances, distributeddatabase instance 114 can be implemented within the compute device 110,as shown in FIG. 1. In other instances, the instance of the distributeddatabase is accessible by the compute device (e.g., via a network), butis not implemented in the compute device (not shown in FIG. 1).

The processor 111 of the compute device 110 can be any suitableprocessing device configured to run and/or execute distributed databaseinstance 114. For example, the processor 111 can be configured to updatedistributed database instance 114 in response to receiving a signal fromcompute device 120, and/or cause a signal to be sent to compute device120, as described in further detail herein. More specifically, asdescribed in further detail herein, the processor 111 can be configuredto execute modules, functions and/or processes to update the distributeddatabase instance 114 in response to receiving a synchronization eventassociated with a transaction from another compute device, a recordassociated with an order of synchronization events, and/or the like. Inother embodiments, the processor 111 can be configured to executemodules, functions and/or processes to update the distributed databaseinstance 114 in response to receiving a value for a parameter stored inanother instance of the distributed database (e.g., distributed databaseinstance 124 at compute device 120), and/or cause a value for aparameter stored in the distributed database instance 114 at computedevice 110 to be sent to compute device 120. In some embodiments, theprocessor 111 can be a general purpose processor, a Field ProgrammableGate Array (FPGA), an Application Specific Integrated Circuit (ASIC), aDigital Signal Processor (DSP), and/or the like.

The display 113 can be any suitable display, such as, for example, aliquid crystal display (LCD), a cathode ray tube display (CRT) or thelike. In other embodiments, any of compute devices 110, 120, 130, 140includes another output device instead of or in addition to the displays113, 123, 133, 143. For example, any one of the compute devices 110,120, 130, 140 can include an audio output device (e.g., a speaker), atactile output device, and/or the like. In still other embodiments, anyof compute devices 110, 120, 130, 140 includes an input device insteadof or in addition to the displays 113, 123, 133, 143. For example, anyone of the compute devices 110, 120, 130, 140 can include a keyboard, amouse, and/or the like.

The compute device 120 has a processor 121, a memory 122, and a display123, which can be structurally and/or functionally similar to theprocessor 111, the memory 112, and the display 113, respectively. Also,distributed database instance 124 can be structurally and/orfunctionally similar to distributed database instance 114.

The compute device 130 has a processor 131, a memory 132, and a display133, which can be structurally and/or functionally similar to theprocessor 111, the memory 112, and the display 113, respectively. Also,distributed database instance 134 can be structurally and/orfunctionally similar to distributed database instance 114.

The compute device 140 has a processor 141, a memory 142, and a display143, which can be structurally and/or functionally similar to theprocessor 111, the memory 112, and the display 113, respectively. Also,distributed database instance 144 can be structurally and/orfunctionally similar to distributed database instance 114.

Even though compute devices 110, 120, 130, 140 are shown as beingsimilar to each other, each compute device of the distributed databasesystem 100 can be different from the other compute devices. Each computedevice 110, 120, 130, 140 of the distributed database system 100 can beany one of, for example, a computing entity (e.g., a personal computingdevice such as a desktop computer, a laptop computer, etc.), a mobilephone, a personal digital assistant (PDA), and so forth. For example,compute device 110 can be a desktop computer, compute device 120 can bea smartphone, and compute device 130 can be a server.

In some embodiments, one or more portions of the compute devices 110,120, 130, 140 can include a hardware-based module (e.g., a digitalsignal processor (DSP), a field programmable gate array (FPGA)) and/or asoftware-based module (e.g., a module of computer code stored in memoryand/or executed at a processor). In some embodiments, one or more of thefunctions associated with the compute devices 110, 120, 130, 140 (e.g.,the functions associated with the processors 111, 121, 131, 141) can beincluded in one or more modules (see, e.g., FIG. 2).

The properties of the distributed database system 100, including theproperties of the compute devices (e.g., the compute devices 110, 120,130, 140), the number of compute devices, and the network 105, can beselected in any number of ways. In some instances, the properties of thedistributed database system 100 can be selected by an administrator ofdistributed database system 100. In other instances, the properties ofthe distributed database system 100 can be collectively selected by theusers of the distributed database system 100.

Because a distributed database system 100 is used, no leader isappointed among the compute devices 110, 120, 130, and 140.Specifically, none of the compute devices 110, 120, 130, or 140 areidentified and/or selected as a leader to settle disputes between valuesstored in the distributed database instances 111, 12, 131, 141 of thecompute devices 110, 120, 130, 140. Instead, using the eventsynchronization processes, the voting processes and/or methods describedherein, the compute devices 110, 120, 130, 140 can collectively convergeon a value for a parameter.

Not having a leader in a distributed database system increases thesecurity of the distributed database system. Specifically, with a leaderthere is a single point of attack and/or failure. If malicious softwareinfects the leader and/or a value for a parameter at the leader'sdistributed database instance is maliciously altered, the failure and/orincorrect value is propagated throughout the other distributed databaseinstances. In a leaderless system, however, there is not a single pointof attack and/or failure. Specifically, if a parameter in a distributeddatabase instance of a leaderless system contains a value, the valuewill change after that distributed database instance exchanges valueswith the other distributed database instances in the system, asdescribed in further detail herein. Additionally, the leaderlessdistributed database systems described herein increase the speed ofconvergence while reducing the amount of data sent between devices asdescribed in further detail herein.

FIG. 2 illustrates a compute device 200 of a distributed database system(e.g., distributed database system 100), according to an embodiment. Insome embodiments, compute device 200 can be similar to compute devices110, 120, 130, 140 shown and described with respect to FIG. 1. Computedevice 200 includes a processor 210 and a memory 220. The processor 210and memory 220 are operatively coupled to each other. In someembodiments, the processor 210 and memory 220 can be similar to theprocessor 111 and memory 112, respectively, described in detail withrespect to FIG. 1. As shown in FIG. 2, the processor 210 includes adatabase convergence module 211 and communication module 210, and thememory 220 includes a distributed database instance 221. Thecommunication module 212 enables compute device 200 to communicate with(e.g., send data to and/or receive data from) other compute devices. Insome embodiments, the communication module 212 (not shown in FIG. 1)enables compute device 110 to communicate with compute devices 120, 130,140. Communication module 210 can include and/or enable, for example, anetwork interface controller (NIC), wireless connection, a wired port,and/or the like. As such, the communication module 210 can establishand/or maintain a communication session between the compute device 200and another device (e.g., via a network such as network 105 of FIG. 1 orthe Internet (not shown)). Similarly stated, the communication module210 can enable the compute device 200 to send data to and/or receivedata from another device.

In some instances, the database convergence module 211 can exchangeevents and/or transactions with other computing devices, store eventsand/or transactions that the database convergence module 211 receives,and calculate an ordering of the events and/or transactions based on thepartial order defined by the pattern of references between the events.Each event can be a record containing a cryptographic hash of twoearlier events (linking that event to the two earlier events and theirancestor events, and vice versa), payload data (such as transactionsthat are to be recorded), other information such as the current time, atimestamp (e.g., date and UTC time) that its creator asserts is the timethe event was first defined, and/or the like. In some instances, thefirst event defined by a member only includes a hash of a single eventdefined by another member. In such instances, the member does not yethave a prior self-hash (e.g., a hash of an event previously defined bythat member). In some instances, the first event in a distributeddatabase does not include a hash of any prior event (since there is noprior event for that distributed database).

In some embodiments, such a cryptographic hash of the two earlier eventscan be a hash value defined based on a cryptographic hash function usingan event as an input. Specifically, in such embodiments, the eventincludes a particular sequence or string of bytes (that represent theinformation of that event). The hash of an event can be a value returnedfrom a hash function using the sequence of bytes for that event as aninput. In other embodiments, any other suitable data associated with theevent (e.g., an identifier, serial number, the bytes representing aspecific portion of the event, etc.) can be used as an input to the hashfunction to calculate the hash of that event. Any suitable hash functioncan be used to define the hash. In some embodiments, each member usesthe same hash function such that the same hash is generated at eachmember for a given event. The event can then be digitally signed by themember defining and/or creating the event.

In some instances, the set of events and their interconnections can forma Directed Acyclic Graph (DAG). In some instances, each event in a DAGreferences two earlier events (linking that event to the two earlierevents and their ancestor events and vice versa), and each reference isstrictly to earlier ones, so that there are no loops. In someembodiments, the DAG is based on cryptographic hashes, so the datastructure can be called a hashDAG. The hashDAG directly encodes apartial order, meaning that event X is known to come before event Y if Ycontains a hash of X, or if Y contains a hash of an event that containsa hash of X, or for such paths of arbitrary length. If, however, thereis no path from X to Y or from Y to X, then the partial order does notdefine which event came first. Therefore, the database convergencemodule can calculate a total order from the partial order. This can bedone by any suitable deterministic function that is used by the computedevices, so that the compute devices calculate the same order. In someembodiments, each member can recalculate this order after each sync, andeventually these orders can converge so that a consensus emerges.

A consensus algorithm can be used to determine the order of events in ahashDAG and/or the order of transactions stored within the events. Theorder of transactions in turn can define a state of a database as aresult of performing those transactions according to the order. Thedefined state of the database can be stored as a database statevariable.

In some instances, the database convergence module can use the followingfunction to calculate a total order from the partial order in thehashDAG. For each of the other compute devices (called “members”), thedatabase convergence module can examine the hashDAG to discover an orderin which the events (and/or indications of those events) were receivedby that member. The database convergence module can then calculate as ifthat member assigned a numeric “rank” to each event, with the rank being1 for the first event that member received, 2 for the second event thatmember received, and so on. The database convergence module can do thisfor each member in the hashDAG. Then, for each event, the databaseconvergence module can calculate the median of the assigned ranks, andcan sort the events by their medians. The sort can break ties in adeterministic manner, such as sorting two tied events by a numeric orderof their hashes, or by some other method, in which the databaseconvergence module of each member uses the same method. The result ofthis sort is the total order.

FIG. 6 illustrates a hashDAG 640 of one example for determining a totalorder. HashDAG 640 illustrates two events (the lowest striped circle andlowest dotted circle) and the first time each member receives anindication of those events (the other striped and dotted circles). Eachmember's name at the top is colored by which event is first in theirslow order. There are more striped initial votes than dotted, thereforeconsensus votes for each of the members are striped. In other words, themembers eventually converge to an agreement that the striped eventoccurred before the dotted event.

In this example, the members (compute devices labeled Alice, Bob, Carol,Dave and Ed) will work to define a consensus of whether event 642 orevent 644 occurred first. Each striped circle indicates the event atwhich a member first received an event 644 (and/or an indication of thatevent 644). Similarly, each dotted circle indicates the event at which amember first received an event 642 (and/or an indication of that event642). As shown in the hashDAG 640, Alice, Bob and Carol each receivedevent 644 (and/or an indication of event 644) prior to event 642. Daveand Ed both received event 642 (and/or an indication of event 642) priorto event 644 (and/or an indication of event 644). Thus, because agreater number of members received event 644 prior to event 642, thetotal order can be determined by each member to indicate that event 644occurred prior to event 642.

In other instances, the database convergence module can use a differentfunction to calculate the total order from the partial order in thehashDAG. In such embodiments, for example, the database convergencemodule can use the following functions to calculate the total order,where a positive integer Q is a parameter shared by the members.

creator(x)=the member who created event x

anc(x)=the set of events that are ancestors of x, including x itself

other(x)=the event created by the member who synced just before x wascreated

self(x)=the last event before x with the same creator

self(x, 0)=self(x)

self(x, n)=self(self(x), n−1)

order(x, y)=k, where y is the kth event that creator(x) learned of

last(x)={y|y ∈ anc(x)

∃z ∈anc(x), (y ∈ anc(z)

creator(y)=creator(z))}

${{slow}\left( {x,y} \right)} = \left\{ {{{\begin{matrix}\infty & {{{{if}\mspace{14mu} y} \notin {{anc}(x)}}\mspace{371mu}} \\{{order}\left( {x,y} \right)} & {{{{if}\mspace{14mu} y} \in {{{anc}(x)}\bigwedge y} \notin {{anc}\left( {{self}(x)} \right)}}\mspace{175mu}} \\{{fast}\left( {x,y} \right)} & {{{if}\mspace{14mu} {\forall{i \in \left\{ {1,\ldots,Q} \right\}}}},{{{fast}\left( {x,y} \right)} = {{fast}\left( {{{self}\left( {x,i} \right)},y} \right)}}} \\{{slow}\left( {{{self}(x)},y} \right)} & {{otherwise}\mspace{410mu}}\end{matrix}{{fast}\left( {x,y} \right)}} = {{the}\mspace{14mu} {position}\mspace{14mu} {of}\mspace{14mu} y\mspace{14mu} {in}\mspace{14mu} a\mspace{14mu} {sorted}\mspace{14mu} {list}}},{{{with}\mspace{14mu} {element}\mspace{14mu} z} \in {{{anc}(x)}{sorted}\mspace{14mu} {by}\mspace{14mu} \underset{w \in {{last}{(x)}}}{median}\mspace{14mu} {{slow}\left( {w,z} \right)}\mspace{14mu} {and}\mspace{14mu} {with}\mspace{14mu} {ties}\mspace{14mu} {broken}\mspace{14mu} {by}\mspace{14mu} {the}\mspace{14mu} {hash}\mspace{14mu} {of}\mspace{14mu} {each}\mspace{14mu} {event}}}} \right.$

In this embodiment, fast(x,y) gives the position of y in the total orderof the events, in the opinion of creator(x), substantially immediatelyafter x is created and/or defined. If Q is infinity, then the abovecalculates the same total order as in the previously describedembodiment. If Q is finite, and all members are online, then the abovecalculates the same total order as in the previously describedembodiment. If Q is finite and a minority of the members are online at agiven time, then this function allows the online members to reach aconsensus among themselves that will remain unchanged as new memberscome online slowly, one by one. If, however, there is a partition of thenetwork, then the members of each partition can come to their ownconsensus. Then, when the partition is healed, the members of thesmaller partition will adopt the consensus of the larger partition.

In still other instances, as described with respect to FIGS. 14-16 b,the database convergence module can use yet a different function tocalculate the total order from the partial order in the hashDAG. Asshown in FIGS. 14-15, each member (Alice, Bob, Carol, Dave and Ed)creates and/or defines events (1401-1413 as shown in FIG. 14; 1501-1506shown in FIG. 15). Using the function and sub-functions described withrespect to FIGS. 14-16 b, the total order for the events can becalculated by sorting the events by their received round, breaking tiesby their received timestamp, and breaking those ties by theirsignatures, as described in further detail herein. In other instances,the total order for the events can be calculated by sorting the eventsby their received round, breaking ties by their received generation(instead of their received timestamp), and breaking those ties by theirsignatures. The following paragraphs specify functions used to calculateand/or define an event's received round and received generation todetermine an order for the events. The following terms are used andillustrated in connection with FIGS. 14-16 b.

-   -   “Parent”: an event X is a parent of event Y if Y contains a hash        of X. For example, in FIG. 14, the parents of event 1412 include        event 1406 and event 1408.    -   “Ancestor”: the ancestors of an event X are X, its parents, its        parents' parents, and so on. For example, in FIG. 14, the        ancestors of event 1412 are events 1401, 1402, 1403, 1406, 1408,        and 1412. Ancestors of an event can be said to be linked to that        event and vice versa.    -   “Descendant”: the descendants of an event X are X, its children,        its children's children, and so on. For example, in FIG. 14, the        descendants of event 1401 are every event shown in the figure.        For another example, the descendants of event 1403 are events        1403, 1404, 1406, 1407, 1409, 1410, 1411, 1412 and 1413.        Descendants of an event can be said to be linked to that event        and vice versa.    -   “N”: the total number of members in the population. For example,        in FIG. 14, the members are compute devices labeled Alice, Bob,        Carol, Dave and Ed, and N is equal to five.    -   “M”: the least integer that is more than a certain percentage of        N (e.g., more than ⅔ of N). For example, in FIG. 14, if the        percentage is defined to be ⅔, then M is equal to four. In other        instances, M could be defined, for example, to be a different        percentage of N (e.g., ⅓, ½, etc.), a specific predefined        number, and/or in any other suitable manner.    -   “Self-parent”: the self-parent of an event X is its parent event        Y created and/or defined by the same member. For example, in        FIG. 14, the self-parent of event 1405 is 1401.    -   “Self-ancestor”: the self-ancestors of an event X are X, its        self-parent, its self-parent's self-parent, and so on.    -   “Sequence Number” (or “SN”): an integer attribute of an event,        defined as the Sequence Number of the event's self-parent, plus        one. For example, in FIG. 14, the self-parent of event 1405 is        1401. Since the Sequence Number of event 1401 is one, the        Sequence Number of event 1405 is two (i.e., one plus one).    -   “Generation Number” (or “GN”): an integer attribute of an event,        defined as the maximum of the Generation Numbers of the event's        parents, plus one. For example, in FIG. 14, event 1412 has two        parents, events 1406 and 1408, having Generation Numbers four        and two, respectively. Thus, the Generation Number of event 1412        is five (i.e., four plus one).    -   “Round Increment” (or “RI”): an attribute of an event that can        be either zero or one.    -   “Round Number” (or “RN”): an integer attribute of an event. In        some instances, Round Number can be defined as the maximum of        the Round Numbers of the event's parents, plus the event's Round        Increment. For example, in FIG. 14, event 1412 has two parents,        events 1406 and 1408, both having a Round Number of one. Event        1412 also has a Round Increment of one. Thus, the Round Number        of event 1412 is two (i.e., one plus one). In other instances,        an event can have a Round Number R if R is the minimum integer        such that the event can strongly see (as described herein) at        least M events defined and/or created by different members,        which all have a round number R−1. If there is no such integer,        the Round Number for an event can be a default value (e.g., 0,        1, etc.). In such instances, the Round Number for an event can        be calculated without using a Round Increment. For example, in        FIG. 14, if M is defined to be the least integer greater than ½        times N, then M is three. Then event 1412 strongly sees the M        events 1401, 1402, and 1408, each of which was defined by a        different member and has a Round Number of 1. The event 1412        cannot strongly see at least M events with Round Number of 2        that were defined by different members. Therefore, the Round        Number for event 1412 is 2. In some instances, the first event        in the distributed database includes a Round Number of 1. In        other instances, the first event in the distributed database can        include a Round Number of 0 or any other suitable number.    -   “Forking”: an event X is a fork with event Y if they are defined        and/or created by the same member, and neither is a        self-ancestor of the other. For example, in FIG. 15, member Dave        forks by creating and/or defining events 1503 and 1504, both        having the same self-parent (i.e., event 1501), so that event        1503 is not a self-ancestor of event 1504, and event 1504 is not        a self-ancestor of event 1503.    -   “Identification” of forking: forking can be “identified” by a        third event created and/or defined after the two events that are        forks with each other, if those two events are both ancestors of        the third event. For example, in FIG. 15, member Dave forks by        creating events 1503 and 1504, neither of which is a        self-ancestor of the other. This forking can be identified by        later event 1506 because events 1503 and 1504 are both ancestors        of event 1506. In some instances, identification of forking can        indicate that a particular member (e.g., Dave) has cheated.    -   “Identification” of an event: an event X “identifies” or “sees”        an ancestor event Y if X has no ancestor event Z that is a fork        with Y. For example, in FIG. 14, event 1412 identifies (also        referred to as “sees”) event 1403 because event 1403 is an        ancestor of event 1412, and event 1412 has no ancestor events        that are forks with event 1403. In some instances, event X can        identify event Y if X does not identify forking prior to        event Y. In such instances, even if event X identifies forking        by the member defining event Y subsequent to event Y, event X        can see event Y. Event X does not identify events by that member        subsequent to forking. Moreover, if a member defines two        different events that are both that member's first events in        history, event X can identify forking and does not identify any        event by that member.    -   “Strong identification” (also referred to herein as “strongly        seeing”) of an event: an event X “strongly identifies” (or        “strongly sees”) an ancestor event Y created and/or defined by        the same member as X, if X identifies Y. Event X “strongly        identifies” an ancestor event Y that is not created and/or        defined by the same member as X, if there exists a set S of        events that (1) includes both X and Y and (2) are ancestors of        event X and (3) are descendants of ancestor event Y and (4) are        identified by X and (5) can each identify Y and (6) are created        and/or defined by at least M different members. For example, in        FIG. 14, if M is defined to be the least integer that is more        than ⅔ of N (i.e., M=1+floor(2N/3), which would be four in this        example), then event 1412 strongly identifies ancestor event        1401 because the set of events 1401, 1402, 1406, and 1412 is a        set of at least four events that are ancestors of event 1412 and        descendants of event 1401, and they are created and/or defined        by the four members Dave, Carol, Bob, and Ed, respectively, and        event 1412 identifies each of events 1401, 1402, 1406, and 1412,        and each of events 1401, 1402, 1406, and 1412 identifies event        1401. Similarly stated, an event X (e.g., event 1412) can        “strongly see” event Y (e.g., event 1401) if X can see at least        M events (e.g., events 1401, 1402, 1406, and 1412) created or        defined by different members, each of which can see Y.    -   “Round R first” event (also referred to herein as a “witness”):        an event is a “round R first” event (or a “witness”) if the        event (1) has Round Number R, and (2) has a self-parent having a        Round Number smaller than R or has no self-parent. For example,        in FIG. 14, event 1412 is a “round 2 first” event because it has        a Round Number of two, and its self-parent is event 1408, which        has a Round Number of one (i.e., smaller than two).        -   In some instances, the Round Increment for an event X is            defined to be 1 if and only if X “strongly identifies” at            least M “round R first” events, where R is the maximum Round            Number of its parents. For example, in FIG. 14, if M is            defined to be the least integer greater than ½ times N, then            M is three. Then event 1412 strongly identifies the M events            1401, 1402, and 1408, all of which are round 1 firsts. Both            parents of 1412 are round 1, and 1412 strongly identifies at            least M round 1 firsts, therefore the round increment for            1412 is one. The events in the diagram marked with “RI=0”            each fail to strongly identify at least M round 1 firsts,            therefore their round increments are 0.        -   In some instances, the following method can be used for            determining whether event X can strongly identify ancestor            event Y. For each round R first ancestor event Y, maintain            an array A1 of integers, one per member, giving the lowest            sequence number of the event X, where that member created            and/or defined event X, and X can identify Y. For each event            Z, maintain an array A2 of integers, one per member, giving            the highest sequence number of an event W created and/or            defined by that member, such that Z can identify W. To            determine whether Z can strongly identify ancestor event Y,            count the number of element positions E such that            A1[E]<=A2[E]. Event Z can strongly identify Y if and only if            this count is greater than M. For example, in FIG. 14,            members Alice, Bob, Carol, Dave and Ed can each identify            event 1401, where the earliest event that can do so is their            events {1404, 1403, 1402, 1401, 1408}, respectively. These            events have sequence numbers A1={1,1,1,1,1}. Similarly, the            latest event by each of them that is identified by event            1412 is event {NONE, 1406, 1402, 1401, 1412}, where Alice is            listed as “NONE” because 1412 cannot identify any events by            Alice. These events have sequence numbers of A2={0,2,1,1,2},            respectively, where all events have positive sequence            numbers, so the 0 means that Alice has no events that are            identified by 1412. Comparing the list A1 to the list A2            gives the results {1<=0, 1<=2, 1<=1, 1<=1, 1<=2} which is            equivalent to {false, true, true, true, true} which has four            values that are true. Therefore, there exists a set S of            four events that are ancestors of 1412 and descendants of            1401. Four is at least M, therefore 1412 strongly identifies            1401.        -   Yet another variation on implementing the method for            determining, with A1 and A2, whether event X can strongly            identify ancestor event Y is as follows. If the integer            elements in both arrays are less than 128, then it is            possible to store each element in a single byte, and pack 8            such elements into a single 64-bit word, and let A1 and A2            be arrays of such words. The most significant bit of each            byte in A1 can be set to 0, and the most significant bit of            each byte in A2 can be set to 1. Subtract the two            corresponding words, then perform a bitwise AND with a mask            to zero everything but the most significant bits, then right            shift by 7 bit positions, to get a value that is expressed            in the C programming language as: ((A 2[i]−A1[i]) &            0x8080808080808080)>>7). This can be added to a running            accumulator S that was initialized to zero. After doing this            multiple times, convert the accumulator to a count by            shifting and adding the bytes, to get ((S & 0xff)+((S>>8) &            0xff)+((S>>16) & 0xff)+((S>>24) & 0xff)+((S>>32) &            0xff)+((S>>40) & 0xff)+((S>>48) & 0xff)+((S>>56) & 0xff)).            In some instances, these calculations can be performed in            programming languages such as C, Java, and/or the like. In            other instances, the calculations can be performed using            processor-specific instructions such as the Advanced Vector            Extensions (AVX) instructions provided by Intel and AMD, or            the equivalent in a graphics processing unit (GPU) or            general-purpose graphics processing unit (GPGPU). On some            architectures, the calculations can be performed faster by            using words larger than 64 bits, such as 128, 256, 512, or            more bits.    -   “Famous” event: a round R event X is “famous” if (1) the event X        is a “round R first” event (or “witness”) and (2) a decision of        “YES” is reached via execution of a Byzantine agreement        protocol, described below. In some embodiments, the Byzantine        agreement protocol can be executed by an instance of a        distributed database (e.g., distributed database instance 114)        and/or a database convergence module (e.g., database convergence        module 211). For example, in FIG. 14, there are five round 1        firsts shown: 1401, 1402, 1403, 1404, and 1408. If M is defined        to be the least integer greater than ½ times N, which is three,        then 1412 is a round 2 first. If the protocol runs longer, then        the hashDAG will grow upward, and eventually the other four        members will also have round 2 firsts above the top of this        figure. Each round 2 first will have a “vote” on whether each of        the round 1 firsts is “famous”. Event 1412 would vote YES for        1401, 1402, and 1403 being famous, because those are round 1        firsts that it can identify. Event 1412 would vote NO for 1404        being famous, because 1412 cannot identify 1404. For a given        round 1 first, such as 1402, its status of being “famous” or not        will be decided by calculating the votes of each round 2 first        for whether it is famous or not. Those votes will then propagate        to round 3 firsts, then to round 4 firsts and so on, until        eventually agreement is reached on whether 1402 was famous. The        same process is repeated for other firsts.        -   A Byzantine agreement protocol can collect and use the votes            and/or decisions of “round R first” events to identify            “famous events. For example, a “round R+1 first” Y will vote            “YES” if Y can “identify” event X, otherwise it votes “NO.”            Votes are then calculated for each round G, for G=R+2, R+3,            R+4, etc., until a decision is reached by any member. Until            a decision has been reached, a vote is calculated for each            round G. Some of those rounds can be “majority” rounds,            while some other rounds can be “coin” rounds. In some            instances, for example, Round R+2 is a majority round, and            future rounds are designated as either a majority or a coin            round (e.g., according to a predefined schedule). For            example, in some instances, whether a future round is a            majority round or a coin round can be arbitrarily            determined, subject to the condition that there cannot be            two consecutive coin rounds. For example, it might be            predefined that there will be five majority rounds, then one            coin round, then five majority rounds, then one coin round,            repeated for as long as it takes to reach agreement.        -   In some instances, if round G is a majority round, the votes            can be calculated as follows. If there exists a round G            event that strongly identifies at least M round G−1 firsts            voting V (where V is either “YES” or “NO”), then the            consensus decision is V, and the Byzantine agreement            protocol ends. Otherwise, each round G first event            calculates a new vote that is the majority of the round G−1            firsts that each round G first event can strongly identify.            In instances where there is a tie rather than majority, the            vote can be designated “YES.”        -   Similarly stated, if X is a round R witness (or round R            first), then the results of votes in rounds R+1, R+2, and so            on can be calculated, where the witnesses in each round are            voting for whether X is famous. In round R+1, every witness            that can see X votes YES, and the other witnesses vote NO.            In round R+2, every witness votes according to the majority            of votes of the round R+1 witnesses that it can strongly            see. Similarly, in round R+3, every witness votes according            to the majority of votes of the round R+2 witness that it            can strongly see. This can continue for multiple rounds. In            case of a tie, the vote can be set to YES. In other            instances, the tie can be set to NO or can be randomly set.            If any round has at least M of the witnesses voting NO, then            the election ends, and X is not famous. If any round has at            least M of the witnesses voting YES, then the election ends,            and X is famous. If neither YES nor NO has at least M votes,            the election continues to the next round.        -   As an example, in FIG. 14, consider some round first event X            that is below the figure shown. Then, each round 1 first            will have a vote on whether X is famous. Event 1412 can            strongly identify the round 1 firsts 1401, 1402, and 1408.            So its vote will be based on their votes. If this is a            majority round, then 1412 will check whether at least M of            {1401, 1402, 1408} have a vote of YES. If they do, then the            decision is YES, and the agreement has been achieved. If at            least M of them vote NO, then the decision is NO, and the            agreement has been achieved. If the vote doesn't have at            least M either direction, then 1412 is given a vote that is            a majority of the votes of those of 1401, 1402, and 1408            (and would break ties by voting YES, if there were a tie).            That vote would then be used in the next round, continuing            until agreement is reached.        -   In some instances, if round G is a coin round, the votes can            be calculated as follows. If event X can identify at least M            round G−1 firsts voting V (where V is either “YES” or “NO”),            then event X will change its vote to V. Otherwise, if round            G is a coin round, then each round G first event X changes            its vote to the result of a pseudo-random determination            (akin to a coin flip in some instances), which is defined to            be the least significant bit of the signature of event X.        -   Similarly stated, in such instances, if the election reaches            a round R+K (a coin round), where K is a designated factor            (e.g., a multiple of a number such as 3, 6, 7, 8, 16, 32 or            any other suitable number), then the election does not end            on that round. If the election reaches this round, it can            continue for at least one more round. In such a round, if            event Y is a round R+K witness, then if it can strongly see            at least M witnesses from round R+K−1 that are voting V,            then Y will vote V. Otherwise, Y will vote according to a            random value (e.g., according to a bit of the signature of            event Y (e.g., least significant bit, most significant bit,            randomly selected bit) where 1=YES and 0=NO, or vice versa,            according to a time stamp of the event Y, using a            cryptographic “shared coin” protocol and/or any other random            determination). This random determination is unpredictable            before Y is created, and thus can increase the security of            the events and consensus protocol.        -   For example, in FIG. 14, if round 2 is a coin round, and the            vote is on whether some event before round 1 was famous,            then event 1412 will first check whether at least M of            {1401, 1402, 1408} voted YES, or at least M of them voted            NO. If that is the case, then 1412 will vote the same way.            If there are not at least M voting in either direction, then            1412 will have a random or pseudorandom vote (e.g., based on            the least significant bit of the digital signature that Ed            created for event 1412 when he signed it, at the time he            created and/or defined it).        -   In some instances, the result of the pseudo-random            determination can be the result of a cryptographic shared            coin protocol, which can, for example, be implemented as the            least significant bit of a threshold signature of the round            number.        -   A system can be built from any one of the methods for            calculating the result of the pseudo-random determination            described above. In some instances, the system cycles            through the different methods in some order. In other            instances, the system can choose among the different methods            according to a predefined pattern.    -   “Received round”: An event X has a “received round” of R if R is        the minimum integer such that at least half of the famous round        R first events (or famous witnesses) with round number R are        descendants of and/or can see X. In other instances, any other        suitable percentage can be used. For example, in another        instance, an event X has a “received round” of R if R is the        minimum integer such that at least a predetermined percentage        (e.g., 40%, 60%, 80%, etc.) of the famous round R first events        (or famous witnesses) with round number R are descendants of        and/or can see X.    -   In some instances, the “received generation” of event X can be        calculated as follows. Find which member created and/or defined        each round R first event that can identify event X. Then        determine the generation number for the earliest event by that        member that can identify X. Then define the “received        generation” of X to be the median of that list.    -   In some instances, a “received timestamp” T of an event X can be        the median of the timestamps in the events that include the        first event by each member that identifies and/or sees X. For        example, the received timestamp of event 1401 can be the median        of the value of the timestamps for events 1402, 1403, 1403, and        1408. In some instances, the timestamp for event 1401 can be        included in the median calculation. In other instances, the        received timestamp for X can be any other value or combination        of the values of the timestamps in the events that are the first        events by each member to identify or see X. For example, the        received timestamp for X can be based on an average of the        timestamps, a standard deviation of the timestamps, a modified        average (e.g., by removing the earliest and latest timestamps        from the calculation), and/or the like. In still other        instances, an extended median can be used.

In some instances, the total order and/or consensus order for the eventsis calculated by sorting the events by their received round, breakingties by their received timestamp, and breaking those ties by theirsignatures. In other instances, the total order for the events can becalculated by sorting the events by their received round, breaking tiesby their received generation, and breaking those ties by theirsignatures. The foregoing paragraphs specify functions used to calculateand/or define an event's received round, received timestamp, and/orreceived generation.

In other instances, instead of using the signature of each event, thesignature of that event XORed with the signatures of the famous eventsor famous witnesses with the same received round and/or receivedgeneration in that round can be used. In other instances, any othersuitable combination of event signatures can be used to break ties todefine the consensus order of events.

In still other instances, instead of defining the “received generation”as the median of a list, the “received generation” can be defined to bethe list itself. Then, when sorting by received generation, two receivedgenerations can be compared by the middle elements of their lists,breaking ties by the element immediately before the middle, breakingthose ties by the element immediately after the middle, and continuingby alternating between the element before those used so far and theelement after, until the tie is broken.

In some instances, the median timestamp can be replaced with an“extended median.” In such instances, a list of timestamps can bedefined for each event rather than a single received timestamp. The listof timestamps for an event X can include the first event by each memberthat identifies and/or sees X. For example, in FIG. 14, the list oftimestamps for event 1401 can include the timestamps for events 1402,1403, 1403, and 1408. In some instances, the timestamp for event 1401can also be included. When breaking a tie with the list of timestamps(i.e., two events have the same received round), the middle timestampsof each event's list (or a predetermined of the first or second of thetwo middle timestamps, if of even length) can be compared. If thesetimestamps are the same, the timestamps immediately after the middletimestamps can be compared. If these timestamps are the same, thetimestamps immediately preceding the middle timestamps can be compared.If these timestamps are also the same, the timestamps after the threealready compared timestamps are compared. This can continue to alternateuntil the tie is broken. Similar to the above discussion, if the twolists are identical, the tie can be broken by the signatures of the twoelements.

In still other instances, a “truncated extended median” can be usedinstead of an “extended median.” In such an instance, an entire list oftimestamps is not stored for each event. Instead, only a few of thevalues near the middle of the list are stored and used for comparison.

The median timestamp received can potentially be used for other purposesin addition to calculating a total order of events. For example, Bobmight sign a contract that says he agrees to be bound by the contract ifand only if there is an event X containing a transaction where Alicesigns that same contract, with the received timestamp for X being on orbefore a certain deadline. In that case, Bob would not be bound by thecontract if Alice signs it after the deadline, as indicated by the“received median timestamp”, as described above.

In some instances, a state of the distributed database can be definedafter a consensus is achieved. For example, if S(R) is the set of eventsthat can be seen by the famous witnesses in round R, eventually all ofthe events in S(R) will have a known received round and receivedtimestamp. At that point, the consensus order for the events in S(R) isknown and will not change. Once this point is reached, a member cancalculate and/or define a representation of the events and their order.For example, a member can calculate a hash value of the events in S(R)in their consensus order. The member can then digitally sign the hashvalue and include the hash value in the next event that member defines.This can be used to inform the other members that that member hasdetermined that the events in S(R) have the given order that will notchange. After at least M of the members (or any other suitable number orpercentage of members) have signed the hash value for S(R) (and thusagreed with the order represented by the hash value), that consensuslist of events along with the list of signatures of the members can forma single file (or other data structure) that can be used to prove thatthe consensus order was as claimed for the events in S(R). In otherinstances, if events contain transactions that update a state of thedistributed database system (as described herein), then the hash valuecan be of the state of the distributed database system after applyingthe transactions of the events in S(R) in the consensus order.

In some instances, M (as described above) can be based on weight valuesassigned to each member, rather than just a fraction, percentage and/orvalue of the number of total members. In such an instance, each memberhas a stake associated with its interest and/or influence in thedistributed database system. Such a stake can be a weight value. Eachevent defined by that member can be said to have the weight value of itsdefining member. M can then be a fraction of the total stake of allmembers. The events described above as being dependent on M will occurwhen a set of members with a stake sum of at least M agree. Thus, basedon their stake, certain members can have a greater influence on thesystem and how the consensus order is derived. In some instances, atransaction in an event can change the stake of one or more members, addnew members, and/or delete members. If such a transaction has a receivedround of R, then after the received round has been calculated, theevents after the round R witnesses will recalculate their round numbersand other information using the modified stakes and modified list ofmembers. The votes on whether round R events are famous will use the oldstakes and member list, but the votes on the rounds after R will use thenew stakes and member list.

The foregoing terms, definitions, and algorithms are used to illustratethe embodiments and concepts described in FIGS. 14-16 b. FIGS. 16a and16b illustrate an example application of a consensus method and/orprocess shown in mathematical form.

In other instances, and as described in further detail herein, thedatabase convergence module 211 can initially define a vector of valuesfor a parameter, and can update the vector of values as it receivesadditional values for the parameter from other compute devices. Forexample, the database convergence module 211 can receive additionalvalues for the parameter from other compute devices via thecommunication module 212. In some instances, the database convergencemodule can select a value for the parameter based on the defined and/orupdated vector of values for the parameter, as described in furtherdetail herein. In some embodiments, the database convergence module 211can also send a value for the parameter to other compute devices via thecommunication module 212, as described in further detail herein.

In some embodiments, the database convergence module 211 can send asignal to memory 220 to cause to be stored in memory 220 (1) the definedand/or updated vector of values for a parameter, and/or (2) the selectedvalue for the parameter based on the defined and/or updated vector ofvalues for the parameter. For example, (1) the defined and/or updatedvector of values for the parameter and/or (2) the selected value for theparameter based on the defined and/or updated vector of values for theparameter, can be stored in a distributed database instance 221implemented in memory 220. In some embodiments, the distributed databaseinstance 221 can be similar to distributed database instances 114, 124,134, 144 of the distributed database system 100 shown in FIG. 1.

In FIG. 2, the database convergence module 211 and the communicationmodule 212 are shown in FIG. 2 as being implemented in processor 210. Inother embodiments, the database convergence module 211 and/or thecommunication module 212 can be implemented in memory 220. In stillother embodiments, the database convergence module 211 and/or thecommunication module 212 can be hardware based (e.g., ASIC, FPGA, etc.).

FIG. 7 illustrates a signal flow diagram of two compute devices syncingevents, according to an embodiment. Specifically, in some embodiments,the distributed database instances 703 and 803 can exchange events toobtain convergence. The compute device 700 can select to sync with thecompute device 800 randomly, based on a relationship with the computedevice 700, based on proximity to the compute device 700, based on anordered list associated with the compute device 700, and/or the like. Insome embodiments, because the compute device 800 can be chosen by thecompute device 700 from the set of compute devices belonging to thedistributed database system, the compute device 700 can select thecompute device 800 multiple times in a row or may not select the computedevice 800 for awhile. In other embodiments, an indication of thepreviously selected compute devices can be stored at the compute device700. In such embodiments, the compute device 700 can wait apredetermined number of selections before being able to select again thecompute device 800. As explained above, the distributed databaseinstances 703 and 803 can be implemented in a memory of compute device700 and a memory of compute device 800, respectively.

FIGS. 3-6 illustrate examples of a hashDAG, according to an embodiment.There are five members, each of which is represented by a dark verticalline. Each circle represents an event. The two downward lines from anevent represent the hashes of two previous events. Every event in thisexample has two downward lines (one dark line to the same member and onelight line to another member), except for each member's first event.Time progresses upward. In FIGS. 3-6, compute devices of a distributeddatabase are indicated as Alice, Bob, Carol, Dave and Ed. In should beunderstood that such indications refer to compute devices structurallyand functionally similar to the compute devices 110, 120, 130 and 140shown and described with respect to FIG. 1.

Example System 1: If the compute device 700 is called Alice, and thecompute device 800 is called Bob, then a sync between them can be asillustrated in FIG. 7. A sync between Alice and Bob can be as follows:

-   -   Alice sends Bob the events stored in distributed database 703.    -   Bob creates and/or defines a new event which contains:        -   a hash of the last event Bob created and/or defined        -   a hash of the last event Alice created and/or defined        -   a digital signature by Bob of the above    -   Bob sends Alice the events stored in distributed database 803.    -   Alice creates and/or defines a new event.    -   Alice sends Bob that event.    -   Alice calculates a total order for the events, as a function of        a hashDAG    -   Bob calculates a total order for the events, as a function of a        hashDAG

At any given time, a member can store the events received so far, alongwith an identifier associated with the compute device and/or distributeddatabase instance that created and/or defined each event. Each eventcontains the hashes of two earlier events, except for an initial event(which has no parent hashes), and the first event for each new member(which has a single parent event hash, representing the event of theexisting member that invited them to join). A diagram can be drawnrepresenting this set of events. It can show a vertical line for eachmember, and a dot on that line for each event created and/or defined bythat member. A diagonal line is drawn between two dots whenever an event(the higher dot) includes the hash of an earlier event (the lower dot).An event can be said to be linked to another event if that event canreference the other event via a hash of that event (either directly orthough intermediary events).

For example, FIG. 3 illustrates an example of a hashDAG 600. Event 602is created and/or defined by Bob as a result of and after syncing withCarol. Event 602 includes a hash of event 604 (the previous eventcreated and/or defined by Bob) and a hash of event 606 (the previousevent created and/or defined by Carol). In some embodiments, forexample, the hash of event 604 included within event 602 includes apointer to its immediate ancestor events, events 608 and 610. As such,Bob can use the event 602 to reference events 608 and 610 andreconstruct the hashDAG using the pointers to the prior events. In someinstances, event 602 can be said to be linked to the other events in thehashDAG 600 since event 602 can reference each of the events in thehashDAG 600 via earlier ancestor events. For example, event 602 islinked to event 608 via event 604. For another example, event 602 islinked to event 616 via events 606 and event 612.

Example System 2: The system from Example System 1, where the event alsoincludes a “payload” of transactions or other information to record.Such a payload can be used to update the events with any transactionsand/or information that occurred and/or was defined since the computedevice's immediate prior event. For example, the event 602 can includeany transactions performed by Bob since event 604 was created and/ordefined. Thus, when syncing event 602 with other compute devices, Bobcan share this information. Accordingly, the transactions performed byBob can be associated with an event and shared with the other membersusing events.

Example System 3: The system from Example System 1, where the event alsoincludes the current time and/or date, useful for debugging,diagnostics, and/or other purposes. The time and/or date can be thelocal time and/or date when the compute device (e.g., Bob) createsand/or defines the event. In such embodiments, such a local time and/ordate is not synchronized with the remaining devices. In otherembodiments, the time and/or date can be synchronized across the devices(e.g., when exchanging events). In still other embodiments, a globaltimer can be used to determine the time and/or date.

Example System 4: The system from Example System 1, where Alice does notsend Bob events created and/or defined by Bob, nor ancestor events ofsuch an event. An event x is an ancestor of an event y if y contains thehash of x, or y contains the hash of an event that is an ancestor of x.Similarly stated, in such embodiments Bob sends Alice the events not yetstored by Alice and does not send events already stored by Alice.

For example, FIG. 4 illustrates an example hashDAG 620 illustrating theancestor events (dotted circles) and descendent events (striped circles)of the event 622 (the black circle). The lines establish a partial orderon the events, where the ancestors come before the black event, and thedescendants come after the black event. The partial order does notindicate whether the white events are before or after the black event,so a total order is used to decide their sequence. For another example,FIG. 5 illustrates an example hashDAG illustrating one particular event(solid circle) and the first time each member receives an indication ofthat event (striped circles). When Carol syncs with Dave to createand/or define event 624, Dave does not send to Carol ancestor events ofevent 622 since Carol is already aware of and has received such events.Instead, Dave sends to Carol the events Carol has yet to receive and/orstore in Carol's distributed database instance. In some embodiments,Dave can identify what events to send to Carol based on what Dave'shashDAG reveals about what events Carol has previously received. Event622 is an ancestor of event 626. Therefore, at the time of event 626,Dave has already received event 622. FIG. 4 shows that Dave receivedevent 622 from Ed who received event 622 from Bob who received event 622from Carol. Furthermore, at the time of event 624, event 622 is the lastevent that Dave has received that was created and/or defined by Carol.Therefore, Dave can send Carol the events that Dave has stored otherthan event 622 and its ancestors. Additionally, upon receiving event 626from Dave, Carol can reconstruct the hashDAG based on the pointers inthe events stored in Carol's distributed database instance. In otherembodiments, Dave can identify what events to send to Carol based onCarol sending event 622 to Dave (not shown in FIG. 4) and Daveidentifying using event 622 (and the references therein) to identify theevents Carol has already received.

Example System 5: The system from Example System 1 where both memberssend events to the other in an order such that an event is not sentuntil after the recipient has received and/or stored the ancestors ofthat event. Accordingly, the sender sends events from oldest to newest,such that the recipient can check the two hashes on each event as theevent is received, by comparing the two hashes to the two ancestorevents that were already received. The sender can identify what eventsto send to the receiver based on the current state of the sender'shashDAG (e.g., a database state variable defined by the sender) and whatthat hashDAG indicates the receiver has already received. Referring toFIG. 3, for example, when Bob is syncing with Carol to define event 602,Carol can identify that event 619 is the last event created and/ordefined by Bob that Carol has received. Therefore, Carol can determinethat Bob knows of that event, and its ancestors. Thus Carol can send Bobevent 618 and event 616 first (i.e., the oldest events Bob has yet toreceive that Carol has received). Carol can then send Bob event 612 andthen event 606. This allows Bob to easily link the events andreconstruct Bob's hashDAG. Using Carol's hashDAG to identify what eventsBob has yet to receive can increase the efficiency of the sync and canreduce network traffic since Bob does not request events from Carol.

In other embodiments, the most recent event can be sent first. If thereceiver determines (based on the hash of the two previous events in themost recent event and/or pointers to previous events in the most recentevent) that they have not yet received one of the two previous events,the receiver can request the sender to send such events. This can occuruntil the receiver has received and/or stored the ancestors of the mostrecent event. Referring to FIG. 3, in such embodiments, for example,when Bob receives event 606 from Carol, Bob can identify the hash ofevent 612 and event 614 in event 606. Bob can determine that event 614was previously received from Alice when creating and/or defining event604. Accordingly, Bob does not need to request event 614 from Carol. Bobcan also determine that event 612 has not yet been received. Bob canthen request event 612 from Carol. Bob can then, based on the hasheswithin event 612, determine that Bob has not received events 616 or 618and can accordingly request these events from Carol. Based on events 616and 618, Bob will then be able to determine that he has received theancestors of event 606.

Example System 6: The system from Example System 5 with the additionalconstraint that when a member has a choice between several events tosend next, the event is chosen to minimize the total number of bytessent so far created and/or defined by that member. For example, if Alicehas only two events left to send Bob, and one is 100 bytes and wascreated and/or defined by Carol, and one is 10 bytes and was createdand/or defined by Dave, and so far in this sync Alice has already sent200 bytes of events by Carol and 210 by Dave, then Alice should send theDave event first, then subsequently send the Carol event. Because210+10<100+200. This can be used to address attacks in which a singlemember either sends out a single gigantic event, or a flood of tinyevents. In the case in which the traffic exceeds a byte limit of mostmembers (as discussed with respect to Example System 7), the method ofExample System 6 can ensure that the attacker's events are ignoredrather than the events of legitimate users. Similarly stated, attackscan be reduced by sending the smaller events before bigger ones (todefend against one giant event tying up a connection). Moreover, if amember can't send each of the events in a single sync (e.g., because ofnetwork limitation, member byte limits, etc.), then that member can senda few events from each member, rather than merely sending the eventsdefined and/or created by the attacker and none (of few) events createdand/or defined by other members.

Example System 7: The system from Example System 1 with an additionalfirst step in which Bob sends Alice a number indicating a maximum numberof bytes he is willing to receive during this sync, and Alice replieswith her limit. Alice then stops sending when the next event wouldexceed this limit. Bob does the same. In such an embodiment, this limitsthe number of bytes transferred. This may increase the time toconvergence, but will reduce the amount of network traffic per sync.

Example System 8: The system from Example System 1, in which thefollowing steps added at the start of the syncing process:

-   -   Alice identifies S, the set of events that she has received        and/or stored, skipping events that were created and/or defined        by Bob or that are ancestors of events created and/or defined by        Bob.    -   Alice identifies the members that created and/or defined each        event in S, and sends Bob the list of the member's ID numbers.        Alice also send a number of events that were created and/or        defined by each member that she has already received and/or        stored.    -   Bob replies with a list of how many events he has received that        were created and/or defined by the other members.    -   Alice then sends Bob only the events that he has yet to receive.        For example, if Alice indicates to Bob that she has received 100        events created and/or defined by Carol, and Bob replies that he        has received 95 events created and/or defined by Carol, then        Alice will send only the most recent 5 events created and/or        defined by Carol.

Example System 9: The system from Example System 1, with an additionalmechanism for identifying and/or handling cheaters. Each event containstwo hashes, one from the last event created and/or defined by thatmember (the “self hash”), and one from the last event created and/ordefined by another member (the “foreign hash”). If a member createsand/or defines two different events with the same self hash, then thatmember is a “cheater”. If Alice discovers Dave is a cheater, byreceiving two different events created and/or defined by him with thesame self hash, then she stores an indicator that he is a cheater, andrefrains from syncing with him in the future. If she discovers he is acheater and yet still syncs with him again and creates and/or defines anew event recording that fact, then Alice becomes a cheater, too, andthe other members who learn of Alice further syncing with Dave stopsyncing with Alice. In some embodiments, this only affects the syncs inone way. For example, when Alice sends a list of identifiers and thenumber of events she has received for each member, she doesn't send anID or count for the cheater, so Bob won't reply with any correspondingnumber. Alice then sends Bob the cheater's events that she has receivedand for which she hasn't received an indication that Bob has receivedsuch events. After that sync is finished, Bob will also be able todetermine that Dave is a cheater (if he hasn't already identified Daveas a cheater), and Bob will also refuse to sync with the cheater.

Example System 10: The system in Example System 9, with the additionthat Alice starts a sync process by sending Bob a list of cheaters shehas identified and of whose events she is still storing, and Bob replieswith any cheaters he has identified in addition to the cheaters Aliceidentified. Then they continue as normal, but without giving counts forthe cheaters when syncing with each other.

Example System 11: The system in Example System 1, with a process thatrepeatedly updates a current state (e.g., as captured by a databasestate variable defined by a member of the system) based on transactionsinside of any new events that are received during syncing. This also caninclude a second process that repeatedly rebuilds that state (e.g., theorder of events), whenever the sequence of events changes, by going backto a copy of an earlier state, and recalculating the present state byprocessing the events in the new order. In some embodiments, the currentstate is a state, balance, condition, and/or the like associated with aresult of the transactions. Similarly stated, the state can include thedata structure and/or variables modified by the transactions. Forexample, if the transactions are money transfers between bank accounts,then the current state can be the current balance of the accounts. Foranother example, if the transactions are associated with a multiplayergame, the current state can be the position, number of lives, itemsobtained, sate of the game, and/or the like associated with the game.

Example System 12: The system in Example System 11, made faster by theuse of “fast clone” arrayList to maintain the state (e.g., bank accountbalances, game state, etc.). A fast clone arrayList is a data structurethat acts like an array with one additional feature: it supports a“clone” operation that appears to create and/or define a new object thatis a copy of the original. The close acts as if it were a true copy,because changes to the clone do not affect the original. The cloningoperation, however, is faster than creating a true copy, becausecreating a clone does not actually involve copying and/or updating theentire contents of one arrayList to another. Instead of having twoclones and/or copies of the original list, two small objects, each witha hash table and a pointer to the original list, can be used. When awrite is made to the clone, the hash table remembers which element ismodified, and the new value. When a read is performed on a location, thehash table is first checked, and if that element was modified, the newvalue from the hash table is returned. Otherwise, that element from theoriginal arrayList is returned. In this way, the two “clones” areinitially just pointers to the original arrayList. But as each ismodified repeatedly, it grows to have a large hash table storingdifferences between itself and the original list. Clones can themselvesbe cloned, causing the data structure to expand to a tree of objects,each with its own hash table and pointer to its parent. A read thereforecauses a walk up the tree until a vertex is found that has the requesteddata, or the root is reached. If vertex becomes too large or complex,then it can be replaced with a true copy of the parent, the changes inthe hash table can be made to the copy, and the hash table discarded. Inaddition, if a clone is no longer needed, then during garbage collectionit can be removed from the tree, and the tree can be collapsed.

Example System 13: The system in Example System 11, made faster by theuse of a “fast clone” hash table to maintain the state (e.g., bankaccount balances, game state, etc.). This is the same as System 12,except the root of the tree is a hash table rather than an arrayList.

Example System 14: The system in Example System 11, made faster by theuse of a “fast clone” relational database to maintain the state (e.g.,bank account balances, game state, etc.). This is an object that acts asa wrapper around an existing Relational Database Management System(RDBMS). Each apparent “clone” is actually an object with an ID numberand a pointer to an object containing the database. When the user's codetries to perform a Structure Query Language (SQL) query on the database,that query is first modified, then sent to the real database. The realdatabase is identical to the database as seen by the client code, exceptthat each table has one additional field for the clone ID. For example,suppose there is an original database with clone ID 1, and then twoclones of the database are made, with IDs 2 and 3. Each row in eachtable will have a 1, 2, or 3 in the clone ID field. When a query comesfrom the user code into clone 2, the query is modified so that the querywill only read from rows that have a 2 or 1 in that field. Similarly,reads to 3 look for rows with a 3 or 1 ID. If the Structured QueryLanguage (SQL) command goes to clone 2 and says to delete a row, andthat row has a 1, then the command should just change the 1 to a 3,which marks the row as no longer being shared by clones 2 and 3, and nowjust being visible to 3. If there are several clones in operation, thenseveral copies of the row can be inserted, and each can be changed tothe ID of a different clone, so that the new rows are visible to theclones except for the clone that just “deleted” the row. Similarly, if arow is added to clone 2, then the row is added to the table with an IDof 2. A modification of a row is equivalent to a deletion then aninsertion. As before, if several clones are garbage collected, then thetree can be simplified. The structure of that tree will be stored in anadditional table that is not accessible to the clones, but is purelyused internally.

Example System 15: The system in Example System 11, made faster by theuse of a “fast clone” file system to maintain the state. This is anobject that acts as a wrapper around a file system. The file system isbuilt on top of the existing file system, using a fast clone relationaldatabase to manage the different versions of the file system. Theunderlying file system stores a large number of files, either in onedirectory, or divided up according to filename (to keep directoriessmall). The directory tree can be stored in the database, and notprovided to the host file system. When a file or directory is cloned,the “clone” is just an object with an ID number, and the database ismodified to reflect that this clone now exists. If a fast clone filesystem is cloned, it appears to the user as if an entire, new hard drivehas been created and/or defined, initialized with a copy of the existinghard drive. Changes to one copy can have no effect on the other copies.In reality, there is just one copy of each file or directory, and when afile is modified through one clone the copying occurs.

Example System 16: The system in Example System 15 in which a separatefile is created and/or defined on the host operating system for eachN-byte portion of a file in the fast clone file system. N can be somesuitable size, such as for example 4096 or 1024. In this way, if onebyte is changed in a large file, only one chunk of the large file iscopied and modified. This also increases efficiency when storing manyfiles on the drive that differ in only a few bytes.

Example System 17: The system in Example System 11 where each memberincludes in some or all of the events they create and/or define a hashof the state at some previous time, along with the number of events thatoccurred up to that point, indicating that the member recognizes and/oridentifies that there is now a consensus on the order of events. After amember has collected signed events containing such a hash from amajority of the users for a given state, the member can then store thatas proof of the consensus state at that point, and delete from memorythe events and transactions before that point.

Example System 18: The system in Example System 1 where operations thatcalculate a median or a majority is replaced with a weighted median orweighted majority, where members are weighted by their “stake”. Thestake is a number that indicates how much that member's vote counts. Thestake could be holdings in a crypto currency, or just an arbitrarynumber assigned when the member is first invited to join, and thendivided among new members that the member invites to join. Old eventscan be discarded when enough members have agreed to the consensus stateso that their total stake is a majority of the stake in existence. Ifthe total order is calculated using a median of ranks contributed by themembers, then the result is a number where half the members have ahigher rank and half have a lower. On the other hand, if the total orderis calculated using the weighted median, then the result is a numberwhere about half of the total stake is associated with ranks lower thanthat, and half above. Weighted voting and medians can be useful inpreventing a Sybil attack, where one member invites a huge number of“sock puppet” users to join, each of whom are simply pseudonymscontrolled by the inviting member. If the inviting member is forced todivide their stake with the invitees, then the sock puppets will not beuseful to the attacker in attempts to control the consensus results.Accordingly, proof of stake may be useful in some circumstances.

Example System 19: The system in Example System 1 in which instead of asingle, distributed database, there are multiple databases in ahierarchy. For example, there might be a single database that the usersare members of, and then several smaller databases, or “chunks”, each ofwhich has a subset of the members. When events happen in a chunk, theyare synced among the members of that chunk and not among members outsidethat chunk. Then, from time to time, after a consensus order has beendecided within the chunk, the resulting state (or events with theirconsensus total order) can be shared with the entire membership of thelarge database.

Example System 20: The system in Example System 11, with the ability tohave an event that updates the software for updating the state (e.g., ascaptured by a database state variable defined by a member of thesystem). For example, events X and Y can contain transactions thatmodify the state, according to software code that reads the transactionswithin those events, and then updates the state appropriately. Then,event Z can contain a notice that a new version of the software is nowavailable. If a total order says the events happen in the order X, Z, Y,then the state can be updated by processing the transactions in X withthe old software, then the transactions in Y with the new software. Butif the consensus order was X, Y, Z, then both X and Y can be updatedwith the old software, which might give a different final state.Therefore, in such embodiments, the notice to upgrade the code can occurwithin an event, so that the community can achieve consensus on when toswitch from the old version to the new version. This ensures that themembers will maintain synchronized states. It also ensures that thesystem can remain running, even during upgrades, with no need to rebootor restart the process.

The systems described above are expected to create and/or achieve anefficient convergence mechanism for distributed consensus, with eventualconsensus. Several theorems can be proved about this, as shown in thefollowing.

Example Theorem 1: If event x precedes event y in the partial order,then in a given member's knowledge of the other members at a given time,each of the other members will have either received an indication of xbefore y, or will not yet have received an indication of y.

Proof: If event x precedes event y in the partial order, then x is anancestor of y. When a member receives an indication of y for the firsttime, that member has either already received an indication of x earlier(in which case they heard of x before y), or it will be the case thatthe sync provides that member with both x and y (in which case they willhear of x before y during that sync, because the events received duringa single sync are considered to have been received in an orderconsistent with ancestry relationships as described with respect toExample System 5). QED

Example Theorem 2: For any given hashDAG, if x precedes y in the partialorder, then x will precede y in the total order calculated for thathashDAG.

Proof: If x precedes y in the partial order, then by theorem 1:

-   -   for all i, rank(i,x)<rank(1,y)

where rank(i,x) is the rank assigned by member i to event x, which is 1if x is the first event received by member i, 2 if it is second, and soon. Let med(x) be the median of the rank(i,x) over all i, and similarlyfor med(y).

For a given k, choose an i1 and i2 such that rank(i1,x) is thekth-smallest x rank, and rank(i2,y) is the kth-smallest y rank. Then:

-   -   rank(i1,x)<rank(i2,y)

This is because rank(i2,y) is greater than or equal to k of the y ranks,each of which is strictly greater than the corresponding x rank.Therefore, rank(i2,y) is strictly greater than at least k of the xranks, and so is strictly greater than the kth-smallest x rank. Thisargument holds for any k.

Let n be the number of members (which is the number of i values). Then nmust be either odd or even. If n is odd, then let k=(n+1)/2, and thekth-smallest rank will be the median. Therefore med(x)<med(y). If n iseven, then when k=n/2, the kth-smallest x rank will be strictly lessthan the kth-smallest y rank, and also the (k+1)th-smallest x rank willbe strictly less than the (k+1)th-smallest y rank. So the average of thetwo x ranks will be less than the average of the two y ranks. Therefore,med(x)<med(y). So in both cases, the median of x ranks is strictly lessthan the median of y ranks. So if the total order is defined by sortingthe actions by median rank, then x will precede y in the total order.QED

Example Theorem 3: If a “gossip period” is the amount of time forexisting events to propagate through syncing to all the members, then:

-   -   after 1 gossip period: all members have received the events    -   after 2 gossip periods: all members agree on the order of those        events    -   after 3 gossip periods: all members know that agreement has been        reached    -   after 4 gossip periods: all members obtain digital signatures        from all other members, endorsing this consensus order.

Proof: Let S0 be the set of the events that have been created and/ordefined by a given time T0. If every member will eventually sync withevery other member infinitely often, then with probability 1 there willeventually be a time T1 at which the events in S0 have spread to everymember, so that every member is aware of all of the events. That is theend of the first gossip period. Let S1 be the set of events that existat time T1 and that didn't yet exist at T0. There will then withprobability 1 eventually be a time T2 at which every member has receivedevery event in set S1, which is those that existed at time T1. That isthe end of the second gossip period. Similarly, T3 is when all events inS2, those existing by T2 but not before T1, have spread to all members.Note that each gossip period eventually ends with probability 1. Onaverage, each will last as long as it takes to perform log2(n) syncs, ifthere are n members.

By time T1, every member will have received every event in S0.

By time T2, a given member Alice will have received a record of each ofthe other members receiving every event in S0. Alice can thereforecalculate the rank for every action in S0 for every member (which is theorder in which that member received that action), and then sort theevents by the median of the ranks. The resulting total order does notchange, for the events in S0. That is because the resulting order is afunction of the order in which each member first received an indicationof each of those events, which does not change. It is possible, thatAlice's calculated order will have some events from S1 interspersedamong the S0 events. Those S1 events may still change where they fallwithin the sequence of S0 events. But the relative order of events in S0will not change.

By time T3, Alice will have learned a total order on the union of S0 andS1, and the relative order of the events in that union will not change.Furthermore, she can find within this sequence the earliest event fromS1, and can conclude that the sequence of the events prior to S1 willnot change, not even by the insertion of new events outside of S0.Therefore, by time T3, Alice can determine that consensus has beenachieved for the order of the events in history prior to the first S1event. She can digitally sign a hash of the state (e.g., as captured bya database state variable defined by Alice) resulting from these eventsoccurring in this order, and send out the signature as part of the nextevent she creates and/or defines.

By time T4, Alice will have received similar signatures from the othermembers. At that point she can simply keep that list of signatures alongwith the state they attest to, and she can discard the events she hasstored prior to the first S1 event. QED

The systems described herein describe a distributed database thatachieves consensus quickly and securely. This can be a useful buildingblock for many applications. For example, if the transactions describe atransfer of crypto currency from one crypto currency wallet to another,and if the state is simply a statement of the current amount in eachwallet, then this system will constitute a crypto currency system thatavoids the costly proof-of-work in existing systems. The automatic ruleenforcement allows this to add features that are not common in currentcrypto currencies. For example, lost coins can be recovered, to avoiddeflation, by enforcing a rule that if a wallet neither sends norreceives crypto currency for a certain period of time, then that walletis deleted, and its value is distributed to the other, existing wallets,proportional to the amount they currently contain. In that way, themoney supply would not grow or shrink, even if the private key for awallet is lost.

Another example is a distributed game, which acts like a MassivelyMultiplayer Online (MMO) game being played on a server, yet achievesthat without using a central server. The consensus can be achievedwithout any central server being in control.

Another example is a system for social media that is built on top ofsuch a database. Because the transactions are digitally signed, and themembers receive information about the other members, this providessecurity and convenience advantages over current systems. For example,an email system with strong anti-spam policies can be implemented,because emails could not have forged return addresses. Such a systemcould also become a unified social system, combining in a single,distributed database the functions currently done by email, tweets,texts, forums, wikis, and/or other social media.

Other applications can include more sophisticated cryptographicfunctions, such as group digital signatures, in which the group as awhole cooperates to sign a contract or document. This, and other formsof multiparty computation, can be usefully implemented using such adistributed consensus system.

Another example is a public ledger system. Anyone can pay to store someinformation in the system, paying a small amount of crypto currency (orreal-world currency) per byte per year to store information in thesystem. These funds can then be automatically distributed to members whostore that data, and to members who repeatedly sync to work to achieveconsensus. It can automatically transfer to members a small amount ofthe crypto currency for each time that they sync.

These examples show that the distributed consensus database is useful asa component of many applications. Because the database does not use acostly proof-of-work, possibly using a cheaper proof-of-stake instead,the database can run with a full node running on smaller computers oreven mobile and embedded devices.

While described above as an event containing a hash of two prior events(one self hash and one foreign hash), in other embodiments, a member cansync with two other members to create and/or define an event containinghashes of three prior events (one self hash and two foreign hashes). Instill other embodiments, any number of event hashes of prior events fromany number of members can be included within an event. In someembodiments, different events can include different numbers of hashes ofprior events. For example, a first event can include two event hashesand a second event can include three event hashes.

While events are described above as including hashes (or cryptographichash values) of prior events, in other embodiments, an event can becreated and/or defined to include a pointer, an identifier, and/or anyother suitable reference to the prior events. For example, an event canbe created and/or defined to include a serial number associated with andused to identify a prior event, thus linking the events. In someembodiments, such a serial number can include, for example, anidentifier (e.g., media access control (MAC) address, Internet Protocol(IP) address, an assigned address, and/or the like) associated with themember that created and/or defined the event and an order of the eventdefined by that member. For example, a member that has an identifier of10 and the event is the 15^(th) event created and/or defined by thatmember can assign an identifier of 1015 to that event. In otherembodiments, any other suitable format can be used to assign identifiersfor events.

In other embodiments, events can contain full cryptographic hashes, butonly portions of those hashes are transmitted during syncing. Forexample, if Alice sends Bob an event containing a hash H, and J is thefirst 3 bytes of H, and Alice determines that of the events and hashesshe has stored, H is the only hash starting with J, then she can send Jinstead of H during the sync. If Bob then determines that he has anotherhash starting with J, he can then reply to Alice to request the full H.In that way, hashes can be compressed during transmission.

While the example systems shown and described above are described withreference to other systems, in other embodiments any combination of theexample systems and their associated functionalities can be implementedto create and/or define a distributed database. For example, ExampleSystem 1, Example System 2, and Example System 3 can be combined tocreate and/or define a distributed database. For another example, insome embodiments, Example System 10 can be implemented with ExampleSystem 1 but without Example System 9. For yet another example, ExampleSystem 7 can be combined and implemented with Example System 6. In stillother embodiments, any other suitable combinations of the examplesystems can be implemented.

While described above as exchanging events to obtain convergence, inother embodiments, the distributed database instances can exchangevalues and/or vectors of values to obtain convergence as described withrespect to FIGS. 3-8. Specifically, for example, FIG. 8 illustrates acommunication flow between a first compute device 400 from a distributeddatabase system (e.g., distributed database system 100) and a secondcompute device 500 from the distributed database system (e.g.,distributed database system 100), according to an embodiment. In someembodiments, compute devices 400, 500 can be structurally and/orfunctionally similar to compute device 200 shown in FIG. 2. In someembodiments, compute device 400 and compute device 500 communicate witheach other in a manner similar to how compute devices 110, 120, 130, 140communicate with each other within the distributed database system 100,shown and described with respect to FIG. 1.

Similar to compute device 200, described with respect to FIG. 2, computedevices 400, 500 can each initially define a vector of values for aparameter, update the vector of values, select a value for the parameterbased on the defined and/or updated vector of values for the parameter,and store (1) the defined and/or updated vector of values for theparameter and/or (2) the selected value for the parameter based on thedefined and/or updated vector of values for the parameter. Each of thecompute devices 400, 500 can initially define a vector of values for aparameter any number of ways. For example, each of compute devices 400,500 can initially define a vector of values for a parameter by settingeach value from the vector of values to equal the value initially storedin distributed database instances 403, 503, respectively. For anotherexample, each of compute devices 400, 500 can initially define a vectorof values for a parameter by setting each value from the vector ofvalues to equal a random value. How the vector of values for a parameteris to be initially defined can be selected, for example, by anadministrator of a distributed database system to which the computedevices 400, 500 belong, or individually or collectively by the users ofthe compute devices (e.g., the compute devices 400, 500) of thedistributed database system.

The compute devices 400, 500 can also each store the vector of valuesfor the parameter and/or the selected value for the parameter indistributed database instances 403, 503, respectively. Each of thedistributed database instances 403, 503 can be implemented in a memory(not shown in FIG. 8) similar to memory 220, shown in FIG. 2.

In step 1, compute device 400 requests from compute device 500 a valuefor a parameter stored in distributed database instance 503 of computedevice 500 (e.g., a value stored in a specific field of the distributeddatabase instance 503). In some embodiments, compute device 500 can bechosen by compute device 400 from a set of compute devices belonging toa distributed database system. The compute device 500 can be chosenrandomly, chosen based on a relationship with the compute device 400,based on proximity to the compute device 400, chosen based on an orderedlist associated with the compute device 400, and/or the like. In someembodiments, because the compute device 500 can be chosen by the computedevice 400 from the set of compute devices belonging to the distributeddatabase system, the compute device 400 can select the compute device500 multiple times in a row or may not select the compute device 500 forawhile. In other embodiments, an indication of the previously selectedcompute devices can be stored at the compute device 400. In suchembodiments, the compute device 400 can wait a predetermined number ofselections before being able to select again the compute device 500. Asexplained above, the distributed database instance 503 can beimplemented in a memory of compute device 500.

In some embodiments, the request from compute device 400 can be a signalsent by a communication module of compute device 400 (not shown in FIG.8). This signal can be carried by a network, such as network 105 (shownin FIG. 1), and received by a communication module of compute device500. In some embodiments, each of the communication modules of computedevices 400, 500 can be implemented within a processor or memory. Forexample, the communication modules of compute devices 400, 500 can besimilar to communication module 212 shown in FIG. 2.

After receiving, from compute device 400, the request for the value ofthe parameter stored in distributed database instance 503, the computedevice 500 sends the value of the parameter stored in distributeddatabase instance 503 to compute device 400 in step 2. In someembodiments, compute device 500 can retrieve the value of the parameterfrom memory, and send the value as a signal through a communicationmodule of compute device 500 (not shown in FIG. 8). In some instance ifthe distributed database instance 503 does not already include a valuefor the parameter (e.g., the transaction has not yet been defined indistributed database instance 503), the distributed database instance503 can request a value for the parameter from the compute device 403(if not already provided in step 1) and store that value for theparameter in the distributed database instance 503. In some embodiments,the compute device 400 will then use this value as the value for theparameter in distributed database instance 503.

In step 3, compute device 400 sends to compute device 500 a value for aparameter stored in distributed database instance 403. In otherembodiments, the value for the parameter stored in distributed databaseinstance 403 (step 1) and the request for the value for the sameparameter stored in distributed database instance 503 (step 3) can besent as a single signal. In other embodiments, the value for theparameter stored in distributed database instance 403 can be sent in asignal different from the signal for the request for the value for theparameter stored in distributed database instance 503. In embodimentswhere the value for the parameter stored in distributed databaseinstance 403 is sent in a signal different from signal for the requestfor the value for the parameter stored in distributed database instance503, the value for the parameter stored in distributed database instance403, the two signals can be sent in any order. In other words, eithersignal can be the sent before the other.

After the compute device 400 receives the value of the parameter sentfrom compute device 500 and/or the compute device 500 receives the valuefor the parameter sent from the compute device 400, in some embodiments,the compute device 400 and/or the compute device 500 can update thevector of values stored in distributed database instance 403 and/or thevector of values stored in distributed database instance 503,respectively. For example, compute devices 400, 500 can update thevector of values stored in distributed database instances 403, 503 toinclude the value of the parameter received by compute devices 400, 500,respectively. Compute devices 400, 500 can also update the value of theparameter stored in distributed database instance 403 and/or the valueof the parameter stored in distributed database instance 503,respectively, based on the updated vector of values stored indistributed database instance 403 and/or the updated vector of valuesstored in distributed database instance 503, respectively.

Although the steps are labeled 1, 2, and 3 in FIG. 8 and in thediscussion above, it should be understood steps 1, 2, and 3 can beperformed in any order. For example, step 3 can be performed beforesteps 1 and 2. Furthermore, communication between compute device 400 and500 is not limited to steps 1, 2, and 3 shown in FIG. 3, as described indetail herein. Moreover, after steps 1, 2 and 3 are complete, thecompute device 400 can select another compute device from the set ofcompute devices within the distributed database system with which toexchange values (similar to steps 1, 2 and 3).

In some embodiments, data communicated between compute devices 400, 500can include compressed data, encrypted data, digital signatures,cryptographic checksums, and/or the like. Furthermore, each of thecompute devices 400, 500 can send data to the other compute device toacknowledge receipt of data previously sent by the other device. Each ofthe compute devices 400, 500 can also ignore data that has beenrepeatedly sent by the other device.

Each of compute devices 400, 500 can initially define a vector of valuesfor a parameter, and store this vector of values for a parameter indistributed database instances 403, 503, respectively. FIGS. 9a-9cillustrate examples of vectors of values for a parameter.

A vector can be any set of values for a parameter (e.g., a onedimensional array of values for a parameter, an array of values eachhaving multiple parts, etc.). Three examples of vectors are provided inFIGS. 9a-9c for purposes of illustration. As shown, each of vectors 410,420, 430 has five values for a particular parameter. It should, however,be understood that a vector of values can have any number of values. Insome instances, the number of values included in a vector of values canbe set by user, situation, randomly, etc.

A parameter can be any data object capable of taking on differentvalues. For example, a parameter can be a binary vote, in which the votevalue can be either “YES” or “NO” (or a binary “1” or “0”). As shown inFIG. 9a , the vector of values 410 is a vector having five binary votes,with values 411, 412, 413, 414, 415 being “YES,” “NO,” “NO,” “YES,” and“YES,” respectively. For another example, a parameter can be a set ofdata elements. FIG. 9b shows an example where the parameter is a set ofalphabet letters. As shown, the vector of values 420 has five sets offour alphabet letters, with values 421, 422, 423, 424, 425 being {A, B,C, D}, {A, B, C, E}, {A, B, C, {A, B, F, G}, and {A, B, G, H},respectively. For yet another example, a parameter can be a rankedand/or ordered set of data elements. FIG. 9c shows an example where theparameter is a ranked set of persons. As shown, vector of values 430 hasfive ranked sets of six persons, with values 431, 432, 433, 434, 435being

-   -   (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank),    -   (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Ed, 6. Frank),    -   (1. Bob, 2. Alice, 3. Carol, 4. Dave, 5. Frank, 6. Ed),    -   (1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank), and    -   (1. Alice, 2. Bob, 3. Ed, 4. Carol, 5. Dave, 6. Frank),        respectively.

After defining a vector of values for a parameter, each of computedevices 400, 500 can select a value for the parameter based on thevector of values for the parameter. This selection can be performedaccording to any method and/or process (e.g., a rule or a set of rules).For example, the selection can be performed according to “majorityrules,” where the value for the parameter is selected to be the valuethat appears in more than 50% of the values included in the vector. Toillustrate, vector of values 410 (shown in FIG. 9a ) includes three“YES” values and two “NO” values. Under “majority rules,” the valueselected for the parameter based on the vector of values would be “YES,”because “YES” appears in more than 50% of values 411, 412, 413, 414, 415(of vector of values 410).

For another example, the selection can be performed according to“majority appearance,” where the value for the parameter is selected tobe a set of data elements, each data element appearing in more than 50%of the values included in the vector. To illustrate using FIG. 9b , dataelements “A,” “B,” and “C” appear in more than 50% of the of values 421,422, 423, 424, 425 of vector of values 420. Under “majority appearance,”the value selected for the parameter based on the vector of values wouldbe {A, B, C} because only these data elements (i.e., “A,” “B,” and “C”)appear in three out of the five values of vector of values 420.

For yet another example, the selection can be performed according to“rank by median,” where the value for the parameter is selected to be aranked set of data elements (e.g., distinct data values within a valueof a vector of values), the rank of each data element equal to themedian rank of that data element across all values included in thevector. To illustrate, the median rank of each data element in FIG. 9cis calculated below:

Alice: (1, 2, 2, 1, 1); median rank=1;

Bob: (2, 1, 1, 2, 2); median rank=2;

Carol: (3, 3, 3, 3, 4); median rank=3;

Dave: (4, 4, 4, 5, 5); median rank=4;

Ed: (5, 5, 6, 4, 3); median rank=5;

Frank: (6, 6, 5, 6, 6); median rank=6.

Thus, under “rank by median,” the value for the ranked set of dataelements calculated based on the vector of values 430 would be (1.Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank). In some embodiments,if two or more data elements have a same median (e.g., a tie), the ordercan be determined by any suitable method (e.g., randomly, firstindication of rank, last indication of rank, alphabetically and/ornumerically, etc.).

For an additional example, the selection can be performed according to“Kemeny Young voting,” where the value for the parameter is selected tobe a ranked set of data elements, the rank being calculated to minimizea cost value. For example, Alice ranks before Bob in vectors of values431, 434, 435, for a total of three out of the five vectors of values.Bob ranks before Alice in vectors of values 432 and 433, for a total oftwo out of the five vectors of values. The cost value for ranking Alicebefore Bob is ⅖ and the cost value for ranking Bob before Alice is ⅗.Thus, the cost value for Alice before Bob is lower, and Alice will beranked before Bob under “Kemeny Young voting.”

It should be understood that “majority rules,” “majority appearance,”“rank by median,” and “Kemeny Young voting” are discussed as examples ofmethods and/or processes that can be used to select a value for theparameter based on the vector of values for the parameter. Any othermethod and/or process can also be used. For example, the value for theparameter can be selected to be the value that appears in more than x %of the values included in the vector, where x % can be any percentage(i.e., not limited to 50% as used in “majority rules”). The percentage(i.e., x %) can also vary across selections performed at differenttimes, for example, in relation to a confidence value (discussed indetail herein).

In some embodiments, because a compute device can randomly select othercompute devices with which to exchange values, a vector of values of acompute device may at any one time include multiple values from anothersingle compute device. For example, if a vector size is five, a computedevice may have randomly selected another compute device twice withinthe last five value exchange iterations. Accordingly, the value storedin the other compute device's distributed database instance would beincluded twice in the vector of five values for the requesting computedevice.

FIGS. 3 and 5 together illustrate, as an example, how a vector of valuescan be updated as one compute device communicates with another computedevice. For example, compute device 400 can initially define a vector ofvalues 510. In some embodiments, the vector of values 510 can be definedbased on a value for a parameter stored in distributed database instance403 at compute device 400. For example, when the vector of values 510 isfirst defined, each value from the vector of values 510 (i.e., each ofvalues 511, 512, 513, 514, 515) can be set to equal the value for theparameter stored in distributed database instance 403. To illustrate, ifthe value for the parameter stored in distributed database instance 403,at the time the vector of values 510 is defined, is “YES,” then eachvalue from the vector of values 510 (i.e., each of values 511, 512, 513,514, 515) would be set to “YES,” as shown in FIG. 10a . When computedevice 400 receives a value for the parameter stored in an instance ofthe distributed database of another compute device (e.g., distributeddatabase instance 504 of compute device 500), compute device 400 canupdate the vector of values 510 to include the value for the parameterstored in distributed database instance 504. In some instances, thevector of values 510 can be updated according to First In, First Out(FIFO). For example, if the compute device 400 receives value 516(“YES”), the compute device 400 can add value 516 to the vector ofvalues 510 and delete value 511 from the vector of values 510, to definevector of values 520, as shown in FIG. 10b . For example, if at a latertime compute device receives values 517, 518, compute device 400 can addvalues 517, 518 to the vector of values 510 and delete value 512, 513,respectively, from the vector of values 510, to define vector of values530, 540, respectively. In other instances, the vector of values 510 canbe updated according to schemes other than First In, First Out, such asLast In, First Out (LIFO).

After the compute device 400 updates the vector of values 510 to definevectors of values 520, 530, and/or 540, the compute device 400 canselect a value for the parameter based on the vector of values 520, 530,and/or 540. This selection can be performed according to any methodand/or process (e.g., a rule or a set of rules), as discussed above withrespect to FIGS. 9a -9 c.

In some instances, compute devices 400, 500 can belong to a distributeddatabase system that stores information related to transactionsinvolving financial instruments. For example, each of compute devices400, 500 can store a binary vote (an example of a “value”) on whether aparticular stock is available for purchase (an example of a“parameter”). For example, the distributed database instance 403 ofcompute device 400 can store a value of “YES,” indicating that theparticular stock is indeed available for purchase. The distributeddatabase instance 503 of compute device 500, on the other hand, canstore a value of “NO,” indicating that the particular stock is notavailable for purchase. In some instances, the compute device 400 caninitially define a vector of binary votes based on the binary votestored in the distributed database instance 403. For example, thecompute device 400 can set each binary vote within the vector of binaryvotes to equal the binary vote stored in the distributed databaseinstance 403. In this case, the compute device 400 can define a vectorof binary votes similar to vector of values 510. At some later time, thecompute device 400 can communicate with compute device 500, requestingcompute device 500 to send its binary vote on whether the particularstock is available for purchase. Once compute device 400 receives thebinary vote of compute device 500 (in this example, “NO,” indicatingthat the particular stock is not available for purchase), the computedevice 400 can update its vector of binary votes. For example, theupdated vector of binary votes can be similar to vector of values 520.This can occur indefinitely, until a confidence value meets apredetermined criterion (described in further detail herein),periodically, and/or the like.

FIG. 11 shows a flow chart 10 illustrating the steps performed by thecompute device 110 within the distributed database system 100, accordingto an embodiment. In step 11, the compute device 110 defines a vector ofvalues for a parameter based on a value of the parameter stored in thedistributed database instance 113. In some embodiments, the computedevice 110 can define a vector of values for the parameter based on avalue for a parameter stored in the distributed database instance 113.In step 12, the compute device 110 chooses another compute device withinthe distributed database system 110 and requests from the chosen computedevice a value for the parameter stored in the distributed databaseinstance of the chosen compute device. For example, the compute device110 can randomly choose the compute device 120 from among computedevices 120, 130, 140, and request from the compute device 120 a valuefor the parameter stored in the distributed database instance 123. Instep 13, compute device 110 (1) receives, from the chosen compute device(e.g., the compute device 120), the value for the parameter stored inthe distributed database instance of the chosen compute device (e.g.,the distributed database instance 123) and (2) sends, to the chosencompute device (e.g., the compute device 120), a value for the parameterstored in the distributed database instance 113. In step 14, the computedevice 110 stores the value for the parameter received from the chosencompute device (e.g., the compute device 120) in the vector of valuesfor the parameter. In step 15, the compute device 110 selects a valuefor the parameter based on the vector of values for the parameter. Thisselection can be performed according to any method and/or process (e.g.,a rule or a set of rules), as discussed above with respect to FIGS.9a-9c . In some embodiments, the compute device 110 can repeat theselection of a value for the parameter at different times. The computedevice 110 can also repeatedly cycle through steps 12 through 14 betweeneach selection of a value for the parameter.

In some instances, the distributed database system 100 can storeinformation related to transactions within a Massively Multiplayer Game(MMG). For example, each compute device belonging to the distributeddatabase system 100 can store a ranked set of players (an example of a“value”) on the order in which a particular item was possessed (anexample of a “parameter”). For example, the distributed databaseinstance 114 of the compute device 110 can store a ranked set of players(1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank), similar to value431, indicating that the possession of the particular item began withAlice, was then passed to Bob, was then passed to Carol, was then passedto Dave, was then passed to Ed, and was finally passed to Frank. Thedistributed database instance 124 of the compute device 120 can store avalue of a ranked set of players similar to value 432: (1. Bob, 2.Alice, 3. Carol, 4. Dave, 5. Ed, 6. Frank); the distributed databaseinstance 134 of the compute device 130 can store a value of a ranked setof players similar to value 433: (1. Bob, 2. Alice, 3. Carol, 4. Dave,5. Frank, 6. Ed); the distributed database instance 144 of the computedevice 140 can store a value of a ranked set of players similar to value434: (1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank); thedistributed database instance of a fifth compute device (not shown inFIG. 1) can store a value of a ranked set of players similar to value435: (1. Alice, 2. Bob, 3. Ed, 4. Carol, 5. Dave, 6. Frank).

After the compute device 110 defines a vector of ranked set of players,the compute device can receive values of ranked sets of players from theother compute devices of the distributed database system 100. Forexample, the compute device 110 can receive (1. Bob, 2. Alice, 3. Carol,4. Dave, 5. Ed, 6. Frank) from the compute device 120; (1. Bob, 2.Alice, 3. Carol, 4. Dave, 5. Frank, 6. Ed) from the compute device 130;(1. Alice, 2. Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank) from the computedevice 140; and (1. Alice, 2. Bob, 3. Ed, 4. Carol, 5. Dave, 6. Frank)from the fifth compute device (not shown in FIG. 1). As the computedevice 110 receives values of ranked sets of players from the othercompute devices, the compute device 110 can update its vector of rankedsets of players to include the values of ranked sets of players receivedfrom the other compute devices. For example, the vector of ranked setsof players stored in distributed database instance 114 of the computedevice 110, after receiving the values of ranked sets listed above, canbe updated to be similar to vector of values 430. After the vector ofranked sets of players has been updated to be similar to vector ofvalues 430, the compute device 110 can select a ranked set of playersbased on the vector of ranked sets of players. For example, theselection can be performed according to “rank by median,” as discussedabove with respect to FIGS. 9a-9c . Under “rank by median,” the computedevice 110 would select (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6.Frank) based on the vector of ranked sets of players similar to vectorof values 430.

In some instances, the compute device 110 does not receive the wholevalue from another compute device. In some instances, the compute device110 can receive an identifier associated with portions of the wholevalue (also referred to as the composite value), such as a cryptographichash value, rather than the portions themselves. To illustrate, thecompute device 110, in some instances, does not receive (1. Alice, 2.Bob, 3. Carol, 4. Ed, 5. Dave, 6. Frank), the entire value 434, from thecompute device 140, but receives only ( 4. Ed, 5. Dave, 6. Frank) fromthe compute device 140. In other words, the compute device 110 does notreceive from the compute device 140 (1. Alice, 2. Bob, 3. Carol),certain portions of the value 434. Instead, the compute device 110 canreceive from the compute device 140 a cryptographic hash valueassociated with these portions of the value 434, i.e., (1. Alice, 2.Bob, 3. Carol).

A cryptographic hash value uniquely represents the portions of the valuethat it is associated with. For example, a cryptographic hashrepresenting (1. Alice, 2. Bob, 3. Carol) will be different fromcryptographic hashes representing:

(1. Alice);

(2. Bob);

(3. Carol);

(1. Alice, 2. Bob);

(2. Bob, 3. Carol);

(1. Bob, 2. Alice, 3. Carol);

(1. Carol, 2. Bob, 3. Alice);

etc.

After the compute device 110 receives from the compute device 140 acryptographic hash value associated with certain portions of the value434, the compute device 110 can (1) generate a cryptographic hash valueusing the same portions of the value 431 stored in the distributeddatabase instance 113 and (2) compare the generated cryptographic hashvalue with the received cryptographic hash value.

For example, the compute device 110 can receive from the compute device140 a cryptographic hash value associated with the certain portions ofthe value 434, indicated by italics: (1. Alice, 2. Bob, 3. Carol, 4. Ed,5. Dave, 6. Frank). The compute device can then generate a cryptographichash value using the same portions of the value 431 (stored in thedistributed database instance 113), indicated by italics: (1. Alice, 2.Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank). Because the italicizedportions of value 434 and the italicized portions of value 431 areidentical, the received cryptographic hash value (associated with theitalicized portions of value 434) will also be identical to thegenerated cryptographic hash value (associated with italicized portionsof value 431).

By comparing the generated cryptographic hash value with the receivedcryptographic hash value, the compute device 110 can determine whetherto request from the compute device 140 the actual portions associatedwith the received cryptographic hash value. If the generatedcryptographic hash value is identical to the received cryptographic hashvalue, the compute device 110 can determine that a copy identical to theactual portions associated with the received cryptographic hash value isalready stored in the distributed database instance 113, and thereforethe actual portions associated with the received cryptographic hashvalue is not needed from the compute device 140. On the other hand, ifthe generated cryptographic hash value is not identical to the receivedcryptographic hash value, the compute device 110 can request the actualportions associated with the received cryptographic hash value from thecompute device 140.

Although the cryptographic hash values discussed above are associatedwith portions of single values, it should be understood that acryptographic hash value can be associated with an entire single valueand/or multiple values. For example, in some embodiments, a computedevice (e.g., the compute device 140) can store a set of values in itsdistributed database instance (e.g., the distributed database instance144). In such embodiments, after a predetermined time period since avalue has been updated in the database instance, after a confidencevalue (discussed with respect to FIG. 13) for the value meets apredetermined criterion (e.g., reaches a predetermined threshold), aftera specified amount of time since the transaction originated and/or basedon any other suitable factors, that value can be included in acryptographic hash value with other values when data is requested fromand sent to another database instance. This reduces the number ofspecific values that are sent between database instances.

In some instances, for example, the set of values in the database caninclude a first set of values, including transactions between the year2000 and the year 2010; a second set of values, including transactionsbetween the year 2010 and the year 2013; a third set of values,including transactions between the year 2013 and the year 2014; and afourth set of values, including transactions between 2014 and thepresent. Using this example, if the compute device 110 requests from thecompute device 140 data stored in distributed database instance 144 ofthe compute device 140, in some embodiments, the compute device 140 cansend to the compute device 110 (1) a first cryptographic hash valueassociated with the first set of values, (2) a second cryptographic hashvalue associated with the second set of values, (3) a thirdcryptographic hash value associated with the third set of values; and(4) each value from the fourth set of values. Criteria for when a valueis added to a cryptographic hash can be set by an administrator,individual users, based on a number of values already in the databaseinstance, and/or the like. Sending cryptographic hash values instead ofeach individual value reduces the number of individual values providedwhen exchanging values between database instances.

When a receiving compute device (e.g., compute device 400 in step 2 ofFIG. 8) receives a cryptographic hash value (e.g., generated by computedevice 500 based on values in distributed database instance 503), thatcompute device generates a cryptographic hash value using the samemethod and/or process and the values in its database instance (e.g.,distributed database instance 403) for the parameters (e.g.,transactions during a specified time period) used to generate thereceived cryptographic hash value. The receiving compute device can thencompare the received cryptographic hash value with the generatedcryptographic hash value. If the values do not match, the receivingcompute device can request the individual values used to generate thereceived cryptographic hash from the sending compute device (e.g.,compute device 500 in FIG. 8) and compare the individual values from thesending database instance (e.g., distributed database instance 503) withthe individual values for those transactions in the received databaseinstance (e.g., distributed database instance 403).

For example, if the receiving compute device receives the cryptographichash value associated with the transactions between the year 2000 andthe year 2010, the receiving compute device can generate a cryptographichash using the values for the transactions between the year 2000 and theyear 2010 stored in its database instance. If the received cryptographichash value matches the locally-generated cryptographic hash value, thereceiving compute device can assume that the values for the transactionsbetween the year 2000 and the year 2010 are the same in both databasesand no additional information is requested. If, however, the receivedcryptographic hash value does not match the locally-generatedcryptographic hash value, the receiving compute device can request theindividual values the sending compute device used to generate thereceived cryptographic hash value. The receiving compute device can thenidentify the discrepancy and update a vector of values for thatindividual value.

The cryptographic hash values can rely on any suitable process and/orhash function to combine multiple values and/or portions of a value intoa single identifier. For example, any suitable number of values (e.g.,transactions within a time period) can be used as inputs to a hashfunction and a hash value can be generated based on the hash function.

Although the above discussion uses cryptographic hash values as theidentifier associated with values and/or portions of values, it shouldbe understood that other identifiers used to represent multiple valuesand/or portions of values can be used. Examples of other identifiersinclude digital fingerprints, checksums, regular hash values, and/or thelike.

FIG. 12 shows a flow chart (flow chart 20) illustrating steps performedby the compute device 110 within the distributed database system 100,according to an embodiment. In the embodiment illustrated by FIG. 12,the vector of values is reset based on a predefined probability.Similarly stated, each value in the vector of values can be reset to avalue every so often and based on a probability. In step 21, the computedevice 110 selects a value for the parameter based on the vector ofvalues for the parameter, similar to step 15 illustrated in FIG. 11 anddiscussed above. In step 22, the compute device 110 receives values forthe parameter from other compute devices (e.g., compute devices 120,130, 140) and sends a value for the parameter stored in the distributeddatabase instance 113 to the other compute devices (e.g., computedevices 120, 130, 140). For example, step 22 can include performingsteps 12 and 13, illustrated in FIG. 11 and discussed above, for each ofthe other compute devices. In step 23, the compute device 110 stores thevalues for the parameter received from the other compute devices (e.g.,compute devices 120, 130, 140) in the vector of values for theparameter, similar to step 14 illustrated in FIG. 11 and discussedabove. In step 24, the compute device 110 determines whether to resetthe vector of values based on a predefined probability of resetting thevector of values. In some instances, for example, there is a 10%probability that the compute device 110 will reset the vector of valuesfor the parameter after each time the compute device 110 updates thevector of values for the parameter stored in distributed databaseinstance 114. In such a scenario, the compute device 110, at step 24,would determine whether or not to reset, based on the 10% probability.The determination can be performed, in some instances, by processor 111of the compute device 110.

If the compute device 110 determines to reset the vector of values basedon the predefined probability, the compute device 110, at step 25,resets the vector of values. In some embodiments, the compute device 110can reset each value in the vector of values for the parameter to equalthe value for the parameter stored in the distributed database instance113 at the time of reset. For example, if, just prior to reset, thevector of values is vector of values 430, and the value for theparameter stored in the distributed database instance 113 is (1. Alice,2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank) (for example, under “rank bymedian”), then each value in the vector of values would be reset toequal (1. Alice, 2. Bob, 3. Carol, 4. Dave, 5. Ed, 6. Frank). In otherwords, each of values 431, 432, 433, 434, 435 of vector of values 430would be reset to equal value 431. Resetting each value in the vector ofvalues for the parameter to equal the value for the parameter stored inthe distributed database instance at the time of reset, every so oftenand based on a probability, aids a distributed database system (to whicha compute device belongs) in reaching consensus. Similarly stated,resetting facilitates agreement on the value for a parameter among thecompute devices of a distributed database system.

For example, the distributed database instance 114 of the compute device110 can store a ranked set of players (1. Alice, 2. Bob, 3. Carol, 4.Dave, 5. Ed, 6. Frank), similar to value 431, indicating that thepossession of the particular item began with Alice, was then passed toBob, was then passed to Carol, was then passed to Dave, was then passedto Ed, and was finally passed to Frank.

FIG. 13 shows a flow chart (flow chart 30) illustrating steps performedby the compute device 110 within the distributed database system 100,according to an embodiment. In the embodiment illustrated by FIG. 13,selection for a value of the parameter based on a vector of values forthe parameter occurs when a confidence value associated with an instanceof the distributed database is zero. The confidence value can indicatethe level of “consensus,” or agreement, between the value of theparameter stored in the compute device 110 and the values of theparameter stored in the other compute devices (e.g., compute devices120, 130, 140) of the distributed database system 100. In someembodiments, as described in detail herein, the confidence value isincremented (e.g., increased by one) each time a value for the parameterreceived from another compute device by the compute device 110 is equalto the value for the parameter stored in the compute device 110, and theconfidence value is decremented (i.e., decreased by one) each time avalue for the parameter received from another compute device by thecompute device 110 does not equal to the value for the parameter storedin the compute device 110, if the confidence value is above zero.

In step 31, the compute device 110 receives a value for the parameterfrom another compute device (e.g., compute device 120) and sends a valuefor the parameter stored in distributed database instance 113 to theother compute device (e.g., compute device 120). For example, step 31can include performing steps 12 and 13, illustrated in FIG. 11 anddiscussed above. In step 32, the compute device 110 stores the value forthe parameter received from the other compute device (e.g., computedevice 120) in the vector of values for the parameter, similar to step14 illustrated in FIG. 11 and discussed above. In step 33, the computedevice 110 determines whether the value for the parameter received fromthe other compute device (e.g., compute device 120) is equal to thevalue for the parameter stored in distributed database instance 113. Ifthe value for the parameter received from the other compute device(e.g., compute device 120) is equal to the value for the parameterstored in distributed database instance 113, then the compute device110, at step 34, increments a confidence value associated withdistributed database instance 113 by one, and the process illustrated byflow chart 30 loops back to step 31. If the value for the parameterreceived from the other compute device (e.g., compute device 120) is notequal to the value for the parameter stored in distributed databaseinstance 113, then the compute device 110, at step 35, decrements theconfidence value associated with distributed database instance 113 byone, if the confidence value is greater than zero.

At step 36, the compute device 110 determines whether confidence valueassociated with distributed database instance 113 is equal to zero. Ifthe confidence value is equal to zero, then the compute device, at step37, selects a value for the parameter based on the vector of values forthe parameter. This selection can be performed according to any methodand/or process (e.g., a rule or a set of rules), as discussed above. Ifthe confidence value is not equal to zero, then the process illustratedby flow chart 30 loops back to step 31.

As discussed above, confidence values are associated with distributeddatabase instances. However, it should be understood that a confidencevalue can also be associated with a value of a vector stored in adistributed database instance and/or the compute device storing thevalue of a vector (e.g., within its distributed database instance)instead of, or in addition to, the distributed database instance.

The values related to the confidence values (e.g., thresholds, incrementvalues, and decrement values) used with respect to FIG. 13 are forillustrative purposes only. It should be understood that other valuesrelated to the confidence values (e.g., thresholds, increment values,and decrement values) can be used. For example, increases and/ordecreases to the confidence value, used in steps 34 and 35,respectively, can be any value. For another example, the confidencethreshold of zero, used in steps 35 and 36, can also be any value.Furthermore, the values related to the confidence values (e.g.,thresholds, increment values, and decrement values) can change duringthe course of operation, i.e., as the process illustrated by flow chart30 loops.

In some embodiments, the confidence value can impact the communicationflow between a first compute device from a distributed database systemand a second compute device from the distributed database system,described above with respect to FIG. 8. For example, if the firstcompute device (e.g., compute device 110) has a high confidence valueassociated with its distributed database instance (e.g., distributeddatabase instance 114), then the first compute device can request fromthe second compute device a smaller portion of a value for a parameter(and a cryptographic hash value associated with a larger portion of thevalue for the parameter) than the first compute device would otherwiserequest from the second compute device (e.g., if the first computedevice has a low confidence value associated with its distributeddatabase instance). The high confidence value can indicate that thevalue for the parameter stored in the first compute device is likely tobe in agreement with values for the parameter stored in other computedevices from the distributed database system and as such, acryptographic hash value is used to verify the agreement.

In some instances, the confidence value of the first compute device canincrease to reach a threshold at which the first compute devicedetermines that it no longer should request particular values,particular portions of values, and/or cryptographic hash valuesassociated with particular values and/or particular portions of valuesfrom other compute devices from the distributed database system. Forexample, if a value's confidence value meets a specific criterion (e.g.,reaches a threshold), the first compute device can determine that thevalue has converged and not further request to exchange this value withother devices. For another example, the value can be added to acryptographic hash value based on its confidence value meeting acriterion. In such instances, the cryptographic hash value for the setof values can be sent instead of the individual value after theconfidence value meets the criterion, as discussed in detail above. Theexchange of fewer values, and/or smaller actual portions (of values)with cryptographic hash values associated with the remaining portions(of values) can facilitate efficient communication among compute devicesof a distributed database system.

In some instances, as the confidence value for specific value of aparameter of a distributed database instance increases, the computedevice associated with that distributed database instance can request toexchange values for that parameter with other compute devices lessfrequently. Similarly, in some instances, as the confidence value for aspecific value of a parameter of a distributed database instancedecreases, the compute device associated with that distributed databaseinstance can request to exchange values for that parameter with othercompute devices more frequently. Thus, the confidence value can be usedto decrease a number of values exchanged between compute devices.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Where methods described above indicate certain eventsoccurring in certain order, the ordering of certain events may bemodified. Additionally, certain of the events may be performedconcurrently in a parallel process when possible, as well as performedsequentially as described above.

Some embodiments described herein relate to a computer storage productwith a non-transitory computer-readable medium (also can be referred toas a non-transitory processor-readable medium) having instructions orcomputer code thereon for performing various computer-implementedoperations. The computer-readable medium (or processor-readable medium)is non-transitory in the sense that it does not include transitorypropagating signals per se (e.g., a propagating electromagnetic wavecarrying information on a transmission medium such as space or a cable).The media and computer code (also can be referred to as code) may bethose designed and constructed for the specific purpose or purposes.Examples of non-transitory computer-readable media include, but are notlimited to: magnetic storage media such as hard disks, floppy disks, andmagnetic tape; optical storage media such as Compact Disc/Digital VideoDiscs (CD/DVDs), Compact Disc-Read Only Memories (CD-ROMs), andholographic devices; magneto-optical storage media such as opticaldisks; carrier wave signal processing modules; and hardware devices thatare specially configured to store and execute program code, such asApplication-Specific Integrated Circuits (ASICs), Programmable LogicDevices (PLDs), Read-Only Memory (ROM) and Random-Access Memory (RAM)devices. Other embodiments described herein relate to a computer programproduct, which can include, for example, the instructions and/orcomputer code discussed herein.

Examples of computer code include, but are not limited to, micro-code ormicro-instructions, machine instructions, such as produced by acompiler, code used to produce a web service, and files containinghigher-level instructions that are executed by a computer using aninterpreter. For example, embodiments may be implemented usingimperative programming languages (e.g., C, Fortran, etc.), functionalprogramming languages (Haskell, Erlang, etc.), logical programminglanguages (e.g., Prolog), object-oriented programming languages (e.g.,Java, C++, etc.) or other suitable programming languages and/ordevelopment tools. Additional examples of computer code include, but arenot limited to, control signals, encrypted code, and compressed code.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, notlimitation, and various changes in form and details may be made. Anyportion of the apparatus and/or methods described herein may be combinedin any combination, except mutually exclusive combinations. Theembodiments described herein can include various combinations and/orsub-combinations of the functions, components and/or features of thedifferent embodiments described.

1.-18. (canceled)
 19. An apparatus, comprising: a memory associated with an instance of a distributed database at a first compute device configured to be included within a plurality of compute devices that implements the distributed database via a network operatively coupled to the plurality of compute devices; and a processor operatively coupled to the memory, the processor configured to identify, at a first time, a first distributed database event (1) defined by the first compute device and (2) linked to a first plurality of distributed database events, the processor configured to receive, at a second time after the first time, a signal representing a second distributed database event (1) defined by a second compute device from the plurality of compute devices and (2) linked to a second plurality of distributed database events, the processor configured to identify an order of distributed database events within a third plurality of distributed database events based at least in part on a value of a first attribute for each distributed database event from the third plurality of distributed database events, the value of the first attribute for each distributed database event from the third plurality of distributed database events being based on a relationship between that distributed database event and a set of distributed database events including descendants of that distributed database event, each distributed database event from the set of distributed database events being associated with a second attribute that is common with the remaining distributed database events from the set of distributed database events, each distributed database event from the third plurality of distributed database events being from at least one of the first plurality of distributed database events or the second plurality of distributed database events, the third plurality of distributed database events being, mutually exclusive of the set of distributed database events, the processor configured to store in the memory the order associated with the third plurality of distributed database events.
 20. The apparatus of claim 19, wherein the value of the first attribute for each distributed database event from the third plurality of distributed database events is based on a number of descendants of that event included in the set of distributed database events compared to a number of non-descendants of that event included in the set of distributed database events.
 21. The apparatus of claim 19, wherein each distributed database event from the set of distributed database events is defined by a unique compute device from the plurality of compute devices.
 22. The apparatus of claim 19, wherein each distributed database event from the set of distributed database events is defined by a unique compute device from the plurality of compute devices, the processor configured to identify each distributed database event from the set of distributed database events based on each distributed database event from the set of distributed database events being an initial instance the compute device from the plurality of compute devices that defined that distributed database event defined a distributed database event having a particular value for a third attribute, each distributed database event from the set of distributed database events having the particular value for the third attribute.
 23. The apparatus of claim 19, wherein the set of distributed database events is a first set of distributed database events, each distributed database event from the first set of distributed database events is defined by a unique compute device from the plurality of compute devices, the processor configured to identify each distributed database event from the first set of distributed database events based on (1) each distributed database event from the first set of distributed database events being an initial instance the compute device from the plurality of compute devices that defined that distributed database event defined a distributed database event having a particular value for a third attribute and (2) an outcome of an agreement protocol in which a second set of distributed database events indicates that that distributed database event from the first set of distributed database events should be within a third set of distributed database events, the first set of distributed database events being a subset of the third set of distributed database events, each distributed database event from the first set of distributed database events having the particular value for the third attribute.
 24. The apparatus of claim 19, wherein each distributed database event from the first plurality of distributed database events and each distributed database event from the second plurality of distributed database events is a sequence of bytes,
 25. The apparatus of claim 19, wherein the set of distributed database events is a first set of distributed database events, the processor configured to identify each distributed database event from the first set of distributed database events based on an outcome of an agreement protocol in which a second set of distributed database events indicates that that distributed database event from the first set of distributed database events should be within a third set of distributed database events, the second set of distributed database events meeting a predetermined criterion, the first set of distributed database events being a subset of the third set of distributed database events.
 26. The apparatus of claim 19, wherein the set of distributed database events is a first set of distributed database events, the processor configured to identify each distributed database event from the first set of distributed database events based on an outcome of an agreement protocol in which a second set of distributed database events indicates that that distributed database event from the first set of distributed database events should be within a third set of distributed database events, the first set of distributed database events being a subset of the third set of distributed database events, the processor configured to identify each distributed database event from the second set of distributed database events based on (1) that distributed database event from the second set of distributed database events being a descendent of a fourth set of distributed database events and (2) a number of distributed database events in the fourth set of distributed database events meeting a criterion.
 27. The apparatus of claim 19, wherein the set of distributed database events is a first set of distributed database events, the processor configured to identify each distributed database event from the first set of distributed database events based on an outcome of an agreement protocol in which a second set of distributed database events indicates that that distributed database event from the first set of distributed database events should be within a third set of distributed database events, the first set of distributed database events being a subset of the third set of distributed database events, the processor configured to identify each distributed database event from the second set of distributed database events based on (1) that distributed database event from the second set of distributed database events being a descendent of a fourth set of distributed database events and (2) a number of distributed database events in the fourth set of distributed database events meeting a first criterion, each distributed database event from the fourth set of distributed database events being an ancestor of a fifth set of distributed database events, each distributed database event from the second set of distributed database events being a descendent of the fifth set of distributed database events, the processor configured to identify each distributed database event from the fourth set of distributed database events based on a number of distributed database events in the fifth set of distributed database events meeting a second criterion.
 28. The apparatus of claim 19, wherein the processor is configured to identify the order associated with the third plurality of distributed database events based at least in part on the value of the first attribute for each distributed database event from the third plurality of distributed database events and a timestamp associated with each distributed database event from the third plurality of distributed database events.
 29. The apparatus of claim 19, wherein the processor is configured to identify the order associated with the third plurality of distributed database events based at least in part on the value of the first attribute for each distributed database event from the third plurality of distributed database events and a signature of each distributed database event from the third plurality of distributed database events.
 30. The apparatus of claim 19, wherein the set of distributed database events is a first set of distributed database events, the processor configured to identify each distributed database event from the first set of distributed database events based on an outcome of an agreement protocol in which a second set of distributed database events indicates that that distributed database event from the first set of distributed database events should be within a third set of distributed database events, each distributed database event from the second set of distributed database events indicating that that distributed database event from the first set of distributed database events should be within the third set of distributed database events based on a value (1) associated with that distributed database event from the first set of distributed database events and (2) identified by a set of ancestors of that distributed database event from the second set of distributed database events.
 31. A non-transitory processor-readable medium storing code representing instructions to be executed by a processor, the code comprising code to cause the processor to: receive a signal representing a plurality of distributed database events including transactions associated with a distributed database; calculate, for each distributed database event from the plurality of distributed database events, a received round for that distributed database event from the plurality of distributed database events based on a relationship between that distributed database event and a set of distributed database events including descendants of that event, each distributed database event from the set of distributed database events being classified as being famous; identify an order associated with the plurality of distributed database events based on the received round associated with each distributed database event from the plurality of distributed database events; and store the order in a memory associated with an instance of a distributed database at a first compute device configured to be included within a plurality of compute devices that implements the distributed database via a network operatively coupled to the plurality of compute devices.
 32. The non-transitory processor-readable medium of claim 31, wherein the code to cause the processor to calculate includes code to cause the processor to calculate, for each distributed database event from the plurality of distributed database events, the received round for that distributed database event based on a number of descendants of that event included in the set of distributed database events compared to a number of non-descendants of that event included in the set of distributed database events.
 33. The non-transitory processor-readable medium of claim 31, wherein the set of distributed database events is a first set of distributed database events, each distributed database event from the first set of distributed database events is defined by a unique compute device from the plurality of compute devices, the code further comprising code to cause the processor to: classify each distributed database event from the first set of distributed database events as famous based on (1) each distributed database event from the first set of distributed database events being an initial instance the compute device from the plurality of compute devices that defined that distributed database event defined a distributed database event having a particular value for an attribute and (2) an outcome of an agreement protocol in which a second set of distributed database events indicates that that distributed database event from the first set of distributed database events should be within a third set of distributed database events, the first set of distributed database events being a subset of the third set of distributed database events, each distributed database event from the first set of distributed database events having the particular value for the attribute.
 34. The non-transitory processor-readable medium of claim 31, wherein each distributed database event from the set of distributed database events is defined by a unique compute device from the plurality of compute devices.
 35. The non-transitory processor-readable medium of claim 31, wherein the set of distributed database events is a first set of distributed database events, the code further comprising code to cause the processor to: classify each distributed database event from the first set of distributed database events as famous based on an outcome of an agreement protocol in which a second set of distributed database events indicates that that distributed database event from the first set of distributed database events should be within a third set of distributed database events, each distributed database event from the second set of distributed database events indicating that that distributed database event from the first set of distributed database events should be within the third set of distributed database events based on a value (1) associated with that distributed database event from the first set of distributed database events and (2) identified by a set of ancestors of that distributed database event from the second set of distributed database events.
 36. The non-transitory processor-readable medium of claim 31, wherein the code to cause the processor to identify the order includes code to cause the processor to identify the order associated with the plurality of distributed database events based at least in part on the received round associated with each distributed database event from the plurality of distributed database events and at least one of a timestamp or a signature of each distributed database event from the plurality of distributed database events,
 37. A method, comprising: identifying, at a first time, a first distributed database event (1) defined by a first compute device configured to be included within a plurality of compute devices that implements the distributed database via a network operatively coupled to the plurality of compute devices and (2) linked to a first plurality of distributed database events; receiving, at a second time after the first time, a signal representing a second distributed database event (1) defined by a second compute device from the plurality of compute devices and (2) linked to a second plurality of distributed database events; calculating, using a processor associated with an instance of the distributed database, an order associated with a third plurality of distributed database events based at least in part on a value of a first attribute for each distributed database event from the third plurality of distributed database events, the value of the first attribute for each distributed database event from the third plurality of distributed database events being based on a relationship between that distributed database event and a set of distributed database events including descendants of that distributed database event, each distributed database event from the set of distributed database events being associated with a second attribute that is common with the remaining distributed database events from the set of distributed database events, each distributed database event from the third plurality of distributed database events being from at least one of the first plurality of distributed database events or the second plurality of distributed database events; and storing, in a memory associated with the instance of the distribute database, the order associated with the third plurality of distributed database events.
 38. The method of claim 37, wherein each distributed database event from the set of distributed database events is defined by a unique compute device from the plurality of compute devices, the method further comprising: identifying each distributed database event from the set of distributed database events based on each distributed database event from the set of distributed database events being a first instance the compute device from the plurality of compute devices that defined that distributed database event defined a distributed database event having a particular value for a third attribute, each distributed database event from the set of distributed database events having the particular value for the third attribute.
 39. The method of claim 37, wherein the set of distributed database events is a first set of distributed database events, the method further comprising: identifying each distributed database event from the first set of distributed database events based on an outcome of an agreement protocol in which a second set of distributed database events indicates that that distributed database event from the first set of distributed database events should be within a third set of distributed database events, each distributed database event from the second set of distributed database events indicating that that distributed database event from the first set of distributed database events should be within the third set of distributed database events based on a value (1) associated with that distributed database event from the first set of distributed database events and (2) identified by a set of ancestors of that distributed database event from the second set of distributed database events.
 40. The method of claim 37, further comprising: calculating the order associated with the third plurality of distributed database events based at least in part on the value of the first attribute for each distributed database event from the third plurality of distributed database events and at least one of a timestamp or a signature of each distributed database event from the third plurality of distributed database events.
 41. The method of claim 37, wherein the value of the first attribute for each distributed database event from the third plurality of distributed database events is based on a number of descendants of that event included in the set of distributed database events compared to a number of non-descendants of that event included in the set of distributed database events. 